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

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

[Marc-André Lureau]

[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]

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

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

Cheers,
-- 
Marc-André Lureau

[-- Attachment #2: 0001-spec-Update-alsa-namespace-to-include-virtual-devic.patch --]
[-- Type: text/x-diff, Size: 5086 bytes --]

From 229891a1a31882575a7c3d625801ffebad7fa5bd Mon Sep 17 00:00:00 2001
From: Marc-Andre Lureau (elmarco) <marcandre.lureau@gmail.com>
Date: Thu, 23 Aug 2007 19:21:04 +0300
Subject: [PATCH] spec: Update alsa namespace to include virtual device

---
 doc/spec/hal-spec-properties.xml |   45 ++++++++++++++++++++++++++++++++------
 1 files changed, 38 insertions(+), 7 deletions(-)

diff --git a/doc/spec/hal-spec-properties.xml b/doc/spec/hal-spec-properties.xml
index 94bc171..0a65d5d 100644
--- a/doc/spec/hal-spec-properties.xml
+++ b/doc/spec/hal-spec-properties.xml
@@ -5007,7 +5007,7 @@ org.freedesktop.Hal.Device.Volume.method_signatures = {'ssas', 'as', 'as'}
       </title>
       <para>
         Device objects with the capability <literal>alsa</literal>
-        represent all the streams available through ALSA on a soundcard.
+        represent all the audio devices available through ALSA. Those could be hardware or software "virtual devices".
       </para>
       <informaltable>
         <tgroup cols="2">
@@ -5025,7 +5025,7 @@ org.freedesktop.Hal.Device.Volume.method_signatures = {'ssas', 'as', 'as'}
                 <literal>alsa.card</literal> (int)
               </entry>
               <entry></entry>
-              <entry>Yes</entry>
+              <entry>If <literal>alsa.is_hardware</literal> is set to TRUE</entry>
               <entry>
                 Card number in system as registered by ALSA.
               </entry>
@@ -5037,7 +5037,7 @@ org.freedesktop.Hal.Device.Volume.method_signatures = {'ssas', 'as', 'as'}
               <entry>
                 Examples: <literal>I82801DBICH4</literal>, <literal>MP3</literal>
               </entry>
-              <entry>No</entry>
+              <entry>If <literal>alsa.is_hardware</literal> is set to TRUE</entry>
               <entry>
                 Textual description of the card.
               </entry>
@@ -5047,7 +5047,7 @@ org.freedesktop.Hal.Device.Volume.method_signatures = {'ssas', 'as', 'as'}
                 <literal>alsa.device</literal> (int)
               </entry>
               <entry></entry>
-              <entry>Yes</entry>
+              <entry>If <literal>alsa.is_hardware</literal> is set to TRUE</entry>
               <entry>
                 Device number assigned by ALSA for a current card.
               </entry>
@@ -5057,13 +5057,24 @@ org.freedesktop.Hal.Device.Volume.method_signatures = {'ssas', 'as', 'as'}
                 <literal>alsa.device_file</literal> (string)
               </entry>
               <entry></entry>
-              <entry>Yes</entry>
+              <entry>If <literal>alsa.is_hardware</literal> is set to TRUE</entry>
               <entry>
                 The device node to access the ALSA device.
               </entry>
             </row>
             <row>
               <entry>
+                <literal>alsa.device_name</literal> (string)
+              </entry>
+	      <entry>Examples: <literal>plug:"hw:0,1"</literal>, <literal>bluetooth:00:19:4F:DB:04:40,hifi</literal>
+	      </entry>
+	      <entry>Yes</entry>
+              <entry>
+                The device name to access the ALSA device. 
+              </entry>
+            </row>
+            <row>
+              <entry>
                 <literal>alsa.device_id</literal> (string)
               </entry>
               <entry>
@@ -5071,7 +5082,7 @@ org.freedesktop.Hal.Device.Volume.method_signatures = {'ssas', 'as', 'as'}
               </entry>
               <entry>No</entry>
               <entry>
-                Textual description of the specific device for a card
+                Textual description of the specific device for a card, or virtual device
               </entry>
             </row>
             <row>
@@ -5139,13 +5150,33 @@ org.freedesktop.Hal.Device.Volume.method_signatures = {'ssas', 'as', 'as'}
                 <literal>alsa.originating_device</literal> (string)
               </entry>
               <entry></entry>
-              <entry>Yes</entry>
+              <entry>If <literal>alsa.is_hardware</literal> is set to TRUE</entry>
               <entry>
                 UDI of the device the ALSA device is bound to.
               </entry>
             </row>
             <row>
               <entry>
+                <literal>alsa.is_hardware</literal> (bool)
+              </entry>
+              <entry></entry>
+              <entry>Yes</entry>
+              <entry>
+                TRUE if it is an hardware device. FALSE if it is a "virtual device".
+              </entry>
+            </row>
+            <row>
+              <entry>
+                <literal>alsa.service</literal> (string)
+              </entry>
+              <entry>example: <literal>Hifi</literal>, <literal>Voice</literal></entry>
+              <entry>No</entry>
+              <entry>
+		Hint of use case of this device.
+              </entry>
+            </row>
+            <row>
+              <entry>
                 <literal>alsa.type</literal> (string)
               </entry>
               <entry></entry>
-- 
1.5.2.3


[-- Attachment #3: Type: text/plain, Size: 141 bytes --]

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

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

[Matthias Kretz]

[-- Attachment #1.1: Type: text/plain, Size: 2441 bytes --]

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/
MatthiasKretz@gmx.net, kretz@kde.org,
Matthias.Kretz@urz.uni-heidelberg.de

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

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

[Marcel Holtmann]

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
hal@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal

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

[Matthias Kretz]

[-- Attachment #1.1: Type: text/plain, Size: 3471 bytes --]

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

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

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

[Marcel Holtmann]

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
hal@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal

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

[Lennart Poettering]

On Thu, 23.08.07 19:22, Marc-Andr=E9 Lureau (marcandre.lureau@gmail.com) 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
hal@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal

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

[Marcel Holtmann]

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
hal@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal

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

[Lennart Poettering]

On Mon, 27.08.07 16:34, Marcel Holtmann (marcel@holtmann.org) 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

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

[Marcel Holtmann]

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
hal@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal

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

[Lennart Poettering]

On Mon, 27.08.07 17:09, Marcel Holtmann (marcel@holtmann.org) 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

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

[Marcel Holtmann]

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
hal@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal