collaborating on bluetooth audio

Lars Hallberg lah at
Sun Jan 28 12:08:14 CET 2007

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.
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 

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.


More information about the community mailing list