Re: [Bluez-devel] work-in-progress bluetooth audio architecture

[Brad Midgley <bmidgley@xmission.com>]

Fabien

> For now i see no reason to merge sco and a2dp daemons into a single
> entity (however i have a set of reasons *not to merge them* :-)

This is what we came up when brainstorming with a group including Marcel
and Nokia developers a couple of weeks ago in Helsinki. We didn't turn
over every use case but it felt like a good approach. The next stage is
to elaborate use cases.

The idea is that the application should just open a default audio device
and the routing smarts are handled by the audio plugin (alsa/gst) in
combination with the daemon. You could just as easily have asked why the
wired audio should be involved, but it's the same argument. The user
should never have to open up preferences and change the audio device
setting in an audio client.

We should be able to tell the difference between an open that needs to
read and write audio (typically for sco) from an open that only writes
(typically for a2dp). If not, we can file a bug. Similar to apps that
won't let the user choose the headset alsa device--it's a bug in the app.

The gui that communicates over dbus will take care of initiating
connect/disconnect and advanced routing, such as enabling both a2dp and
wired output simultaneously.

Which cases are you worried will be trouble?

Brad

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel