_______________________________________________
hal mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/hal
Hi Lennart,
> > > A stable plugin API is not going to happen anytime soon, sorry. Also,
> > > it is not really practical to develop plugins out-of-tree. I
> > > acknowledge the demand for it, but the plugin API is just too quickly
> > > moving.
> > >
> > > Hmm, I'd love to add proper BT support to PA myself, but unfortunately
> > > I lack the hardware for it. It would be much easier to keep it up to
> > > date for me then.
> >
> > We are in a chicken-egg situation here. To write a plugin you need to
> > use our SBC encoder and our IPC. Both of them are internal only.
>
> Hmm, is it going to stay "internal"? Or are you going to stabilize the
> API for it eventually? How volatile is that API?
that is fully 100% unstable right now. The IPC is totally unclear how it
has to look like in the end. It only works right now.
We might get the SBC encoder in a why it could be released as its own
library, but I prefer not doing it right now. It would actually slow
down the development process.
Regards
Marcel
_______________________________________________
hal mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/hal
On Mon, 27.08.07 17:09, Marcel Holtmann ([email protected]) wrote:
> > > > 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.
> >
> > A stable plugin API is not going to happen anytime soon, sorry. Also,
> > it is not really practical to develop plugins out-of-tree. I
> > acknowledge the demand for it, but the plugin API is just too quickly
> > moving.
> >
> > Hmm, I'd love to add proper BT support to PA myself, but unfortunately
> > I lack the hardware for it. It would be much easier to keep it up to
> > date for me then.
>
> We are in a chicken-egg situation here. To write a plugin you need to
> use our SBC encoder and our IPC. Both of them are internal only.
Hmm, is it going to stay "internal"? Or are you going to stabilize the
API for it eventually? How volatile is that API?
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
Hi Lennart,
> > 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.
>
> If the bt devices are exported in sysfs in the kernel already it is no
> longer hal that synthesizes them. Which makes these things much
> cleaner I would say.
>
> Synthesizing virtual devices at the HAL level doesn't look like such a
> good idea to me, smells kludgy. But doing this on a lower level might
> make sense.
the physical link (the piconet connection) is exported via the kernel
and visible via sysfs. If you run RFCOMM (serial port), BNEP (network)
or HIDP (input) over it then it links it together. If the protocol runs
in userspace like A2DP for stereo headsets then the kernel knows nothing
about it and can't link it together. This also means that HAL can't do
anything about it since it lacks these information.
In the overall end there should be no difference in a physical sound
card or a virtual one that use Bluetooth (or Wireless USB or whatever).
The only big difference is actually that these are connected or
disconnected. It is more than hotplug since we can virtually plugin
these devices by connecting to them. And so on. Not really trivial to
solve. My current goal is the less userspace application need to know
the better.
> > > 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.
>
> A stable plugin API is not going to happen anytime soon, sorry. Also,
> it is not really practical to develop plugins out-of-tree. I
> acknowledge the demand for it, but the plugin API is just too quickly
> moving.
>
> Hmm, I'd love to add proper BT support to PA myself, but unfortunately
> I lack the hardware for it. It would be much easier to keep it up to
> date for me then.
We are in a chicken-egg situation here. To write a plugin you need to
use our SBC encoder and our IPC. Both of them are internal only.
Regards
Marcel
_______________________________________________
hal mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/hal
On Mon, 27.08.07 16:34, Marcel Holtmann ([email protected]) wrote:
> 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.
If the bt devices are exported in sysfs in the kernel already it is no
longer hal that synthesizes them. Which makes these things much
cleaner I would say.
Synthesizing virtual devices at the HAL level doesn't look like such a
good idea to me, smells kludgy. But doing this on a lower level might
make sense.
But anyway, it's your call, you're the BT guru.
> > 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.
A stable plugin API is not going to happen anytime soon, sorry. Also,
it is not really practical to develop plugins out-of-tree. I
acknowledge the demand for it, but the plugin API is just too quickly
moving.
Hmm, I'd love to add proper BT support to PA myself, but unfortunately
I lack the hardware for it. It would be much easier to keep it up to
date for me then.
Hmm, I will try to get myself a bt headset.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
Hi Lennart,
> > 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
[email protected]
http://lists.freedesktop.org/mailman/listinfo/hal
On Thu, 23.08.07 19:22, Marc-Andr=E9 Lureau ([email protected]) wr=
ote:
> Hi
> =
> 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 wit=
h 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.
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.
> Thus, a mandatory property "is_hardware" is introduced. If this value
> is true, the current mandatory keys remain mandatory. If not, then the
> client should use "device_name" to "open" the device.
> =
> Arguable:
> - should "device_name" be optional? (currently, application hard-code
> the prefix "hw")
Hmm. I don't think "device_name" makes sense. For example, if one is
interested in surround audio one has to open the device as
surround51:0, or if one wants spdif one has to open it as iec985:0. The
prefix "hw:" is only relevant for stereo analog outputs. =
What I would like to see is that the ALSA devices in HAL would export
a property which tells us which prefixes make sense. I.e. one that
tells me in advance that a device is capable of surround sound, or has
a SPDIF output.
Lennart
-- =
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
_______________________________________________
hal mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/hal
Hi Matthias,
> > 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]"?
the .asoundrc is optional. It is more a convenient file to set the
default PCM or friendly PCM names in case you use aplay etc. You can
always specify the plugin name and its parameters.
In case of Bluetooth this means we will even auto-connect to that device
if not connected. At some point you even be able to use it even if not
connected. In this case you will hear and get silence.
> 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.
And why shouldn't they show up as ALSA device? They are ALSA devices.
You must realize that Bluetooth is only a transport. And yes, we can
export Bluetooth devices with audio attributes in HAL. We will actually
do this at some point in a really generic way, but that doesn't help in
this case.
The extended ALSA syntax is a way to help applications to find a
possible sound device. If you separate device by transport then every
application needs to be changed to find Bluetooth devices. Why should
they know about it. The application wants to use ALSA for sound input
and output. So they ask HAL for an ALSA device. If this happens to be
using Bluetooth. Who cares? The application certainly doesn't.
While Bluetooth has always been the first technology pushing for changes
in various subsystem, it will not be the last. So having a generic way
for notifying about virtual sound cards and giving an ALSA device string
to the application that will do the right thing is the correct approach.
Otherwise you have to change applications again, when Wireless USB,
Ultra-wideband or whatever comes along and allows sound input and output
over virtual hardware.
Regards
Marcel
_______________________________________________
hal mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/hal
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/
[email protected], [email protected],
[email protected]
Hi Matthias,
> I don't agree with this approach, i.e. the listing of virtual ALSA devices
> through HAL, especially the forcing of the device_name. The application might
> be smarter than HAL, once it knows enough about the hardware. For example the
> hw: devices in many cases are not what you want...
>
> Since libasound 1.0.14 we have snd_device_name_hint available to list virtual
> devices (they get listed once you add a hint section in your .asoundrc file).
> What we're missing is a way to link virtual devices to hardware, meaning if
> Hardware "xy" becomes available virtual device "foo" starts to be useful
> (only "polling" works from what I know).
>
> So what I'd like to see is something along the lines of:
> - HAL notifies me that a Bluetooth device with audio support became available.
> - With the id I get from HAL I can query libasound which virtual devices are
> using this device, or if that's not possible iterate over all virtual devices
> that didn't work before and try to open them and see whether they work now.
>
> You made the example "bluetooth:00:19:4F:DB:04:40,hifi" in the patch. Is it
> possible to always access ALSA bluetooth devices that way? Then perhaps the
> HAL entry on the bluetooth device should list give me the necessary hints to
> construct that string myself?
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.
Regards
Marcel
_______________________________________________
hal mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/hal
On Thursday 23 August 2007, Marc-Andr? Lureau wrote:
> 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).
>
> Thus, a mandatory property "is_hardware" is introduced. If this value
> is true, the current mandatory keys remain mandatory. If not, then the
> client should use "device_name" to "open" the device.
>
> Arguable:
> - should "device_name" be optional? (currently, application hard-code
> the prefix "hw")
> - "service" is used to make a difference between a2dp and hfp/hsp
> - "device_name", and "service" key naming
Hi,
I don't agree with this approach, i.e. the listing of virtual ALSA devices
through HAL, especially the forcing of the device_name. The application might
be smarter than HAL, once it knows enough about the hardware. For example the
hw: devices in many cases are not what you want...
Since libasound 1.0.14 we have snd_device_name_hint available to list virtual
devices (they get listed once you add a hint section in your .asoundrc file).
What we're missing is a way to link virtual devices to hardware, meaning if
Hardware "xy" becomes available virtual device "foo" starts to be useful
(only "polling" works from what I know).
So what I'd like to see is something along the lines of:
- HAL notifies me that a Bluetooth device with audio support became available.
- With the id I get from HAL I can query libasound which virtual devices are
using this device, or if that's not possible iterate over all virtual devices
that didn't work before and try to open them and see whether they work now.
You made the example "bluetooth:00:19:4F:DB:04:40,hifi" in the patch. Is it
possible to always access ALSA bluetooth devices that way? Then perhaps the
HAL entry on the bluetooth device should list give me the necessary hints to
construct that string myself?
Anyway, great to hear that bluetooth ALSA support is progressing! I'm really
looking forward to supporting it (now all I need is bluetooth devices...)
--
________________________________________________________
Matthias Kretz (Germany) <><
http://Vir.homelinux.org/
[email protected], [email protected],
[email protected]