Re: [Bluez-devel] [patch] spec: Update alsa namespace to include virtual device

On Thursday 23 August 2007, Marcel Holtmann wrote:

when it comes to Bluetooth and other virtual devices with no real
hardware as backend the world changes a bit. You really do have to
change your way of thinking here since ALSA isn't the central place of
information anymore. Actually ALSA has no clue whatsoever.

The Bluetooth audio support is designed around a central audio daemon
that takes care of mono headsets and high quality stereo headsets. This
daemon does all needed protocol handling and can be controlled via
D-Bus. Without this daemon you don't get any sound at all. This daemon
however handles only the control part of the audio protocol. All the
real audio data encoding and decoding is done in a plugin. Besides the
currently existing ALSA plugin, we have plans for GStreamer and
PulseAudio plugins.

In case of the ALSA plugin you can use it to connect to the default
headset or using a specific remote device address. This all works in the
background and yes, if you get the hint listing right it would show up
in applications that can list virtual devices. However the .asoundrc is
user specific and not touched by the audio daemon. The daemon is a
system process that can handle multiple headsets at one time which could
be used by different users on the same system.

So for the audio daemon, we don't know anything about the user and its
settings and we actually don't care at all. We know that we have a
configured device that can be used via the ALSA plugin with this
specific Bluetooth address. That is what we know and that is what we
will give to HAL. What the user does with this information is fully up
to the user and not the daemons responsibility.

This means whatever kind of hint system you have or don't have, it
doesn't give us any advantage. Please remember that virtual sounds cards
are totally dynamic. They come and go as they like. The daemon is fully
integrated into the Bluetooth authorization framework and for example a
headset can decide to connect back to your machine when you press its
button and it becomes available and usable at exactly that point.
The .asoundrc is to static for this. The only unique identifier that can
be used to identify a Bluetooth headset is its address. The profile to
use (mono or stereo) can be a second parameter, but the daemon can
determine the best profile to use by itself.

Thanks a lot. I think I understand the issue a bit better now.

Questions:
- the entry in .asoundrc as documented on 
http://wiki.bluez.org/wiki/HOWTO/AudioDevices#Alsaconfiguration is optional
- using the ALSA plugin a bluetooth audio device can always (when it's 
connected and authorized) be accessed 
using "bluetooth:<address>[,parameter]"?

If that is so, then I suggest to list a bluetooth device advertising its audio 
capabilities (this possibly means to say what parameters are supported) and 
its address. Then an application can construct the ALSA "device" string 
itself or, if it has the support, use that information to talk with the 
bluetooth device directly.

That would mean those devices don't show up as ALSA devices in HAL at all.

-- 
________________________________________________________
Matthias Kretz (Germany)                            <><
http://Vir.homelinux.org/
MatthiasKretz@gmx.net, kretz@kde.org,
Matthias.Kretz@urz.uni-heidelberg.de