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

Hi Lennart,

quoted

Thanks to the great work of Bluez-guys, bluez-utils audio service is
now able to deal with several audio devices. Those Bluetooth devices
are accessed by a "bluetooth" ALSA plugin (see
http://wiki.bluez.org/wiki/HOWTO/AudioDevices)

There is only a few missing pieces to make those devices discoverable with HAL.

The following patch changes the "alsa" namespace so that "virtual
devices" can also be described (a former approach was to use
alsa.virtual or alsa_virtual new namespace, but alsa.virtual does not
inherit alsa property, and both namespaces have a lot in common).

Uh oh. I am not convinced that adding "virtual" devices to the HAL
tree is a good idea. I mean, bt is basically a transport protocol and
audio-over-bt just a service offered via bt. I mean, you wouldn't want
to include all Avahi-found hw devices in the HAL tree, would you?

Let's keep services out of HAL. HAL should be for hw devices only.  Of
course, it is difficult to draw the line here.

Bluetooth is meant as cable replacement and in the same way as with
Wireless USB in the near future we do have a virtual cable between these
devices. The problem here is to export these information in a fully
generic way since the kernel doesn't know about them (compared to USB
and PCI for example). Our Bluetooth audio service has all the
information about configured audio headsets available, but HAL doesn't.
This means that all the audio applications don't see any Bluetooth
headsets until they include code to discover them via our audio service.
We don't want that, because it would mean that we have to touch every
audio application which is not needed. They don't care how it makes
sounds as long as they hear something.

As you said, Bluetooth is only a transport. It is like USB, PCI or
anything else we consider physically attached. There is no difference
here except that the physical connection is a radio. We try to make this
as transparent as possible. Meaning we auto-connect, re-connect etc. in
the background so that applications don't even have to care at all. To
make this work, Bluetooth has to look like any other hardware device.

At some point in the future we gonna integrate Bluetooth much deeper
into HAL as currently done. Right now we only see the kernel side of
Bluetooth represented in HAL. This needs some restructure to make it
work smoothly and needs some extra time, but we are getting there.

OTOH i must say that this would make it very easy for me to add bt
support to PA, so I am not inherently opposed. However, I don't really
think going through ALSA for bt audio makes too much sense for PA. It
is probably better to integrate bt and PA directly, without having
this unnecessary abstraction in between.

I am currently working on the GStreamer sink. If you provide an exported
plugin API for PulseAudio, you can have that easily. Otherwise it might
not happen.

Regards

Marcel


_______________________________________________
hal mailing list
hal@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal