Brad Midgley skrev:
Koen
> After reading the LCA slides on pulse-audio it seems to be the
best choice for an
> audiorouting app
FYI, I mocked up some diagrams including one that incorporates pulse.
I am hoping to have some of these ideas validated, so let me know if
you have any thoughts on it.
http://bluetooth-alsa.sourceforge.net/future.html#pulse
I like the use of D-bus for finding out whats there and hove to use it.
But there really should be *one* audio connection manager. Were I can
find a headset whether it is connected by usb or blutooth or anything
else. And find out hove to connect to it (preferably in many ways, ie:
hove to build a gst stream, hove to connect by pulse, hove to get a dsp
interface, hove to get at it with alsa, hove to get at it by some
lowlevel interface (eg: by blutooth directly). So an app can choose to
connect the best way it know.
For apps that don't care much for latency, it shuld be possible
streaming the sound by D-bus, encoded with mimetype, or tell the D-bus
service to play a file with (optionally?) given mimetype. Record to a
file or D-bus stream into given mimetype. Then those apps only need to
know hove to talk D-bus to get sound support. Don't need to know
anything about encoders or conections, just ask the system what is
supported.
That gives a few D-bus services:
General audio connection mgt, possably xfer agent.
Blutooth audio device discovery agent.
USB audio device discovery agent.
Build audio connection service (possably several different
'protocol'/sources/targets). Support for mixer to?
D-bus audio sink (passably several different for different formats -
destinations). Support volume?
D-bus audio source (passably several different for different formats -
source). Support volume?
This can be implemented in one demon, in several demons, inside other
demons (like ones who discover other usb/blutooth devices). D-bus
activation should let the app just talk to the D-bus interface the
General audio connection manager point it to. Even pulse could be
started on demand if we want :-)
It need not be implemented in one shot ether. It's possably starting out
supporting, say, only pulse and only main audio and blutooth. But USB
shuld be a priority too.
The D-bus audio sink/source may be left to more advanced media player
apps/libs to implement. The audio connection mgr only need interface to
register services and offer them.
/LaH
_______________________________________________
OpenMoko community mailing list
[email protected]
https://lists.openmoko.org/mailman/listinfo/community
