Other types of usb audio devices.

Other types of usb audio devices.

[James Courtier-Dutton]

Hi,

The current snd-usb-audio driver assumes that the audio device is 
attached to this computer, so it only talks to this endpoint.
If I have an audio usb device with USB_CLASS = 0xe0, it will be a 
wireless device. I.E. A bluetooth headset.
It uses isoc's just like the current snd-usb-audio driver but adds some 
extra requirements, in order to open a connection, one needs to also 
know the bd address of the destination device  (Like a MAC address for 
ethernet) and keep tabs of connection number.
The current bluetooth stack I am using is bluez, from the current 2.4.20 
  kernel, and it uses network sockets for the audio. I would prefer to 
use alsa for sending and receiving audio to/from the headset, with all 
other control of the device going via the bluetooth stack.
So the question is: -
How do I get the bdaddr to alsa so that an application can use 
snd_pcm_open with the bluetooth headset, just as if it was a local audio 
card.
I will probably be writing a new usb-audio.c file and probably call it 
usb-wireless.c in order to handle all the bluetooth specific stuff.

Cheers
James



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01

Re: Other types of usb audio devices.

[Jaroslav Kysela]

On Sat, 5 Jul 2003, James Courtier-Dutton wrote:

> Hi,
> 
> The current snd-usb-audio driver assumes that the audio device is 
> attached to this computer, so it only talks to this endpoint.
> If I have an audio usb device with USB_CLASS = 0xe0, it will be a 
> wireless device. I.E. A bluetooth headset.
> It uses isoc's just like the current snd-usb-audio driver but adds some 
> extra requirements, in order to open a connection, one needs to also 
> know the bd address of the destination device  (Like a MAC address for 
> ethernet) and keep tabs of connection number.
> The current bluetooth stack I am using is bluez, from the current 2.4.20 
>   kernel, and it uses network sockets for the audio. I would prefer to 
> use alsa for sending and receiving audio to/from the headset, with all 
> other control of the device going via the bluetooth stack.
> So the question is: -
> How do I get the bdaddr to alsa so that an application can use 
> snd_pcm_open with the bluetooth headset, just as if it was a local audio 
> card.

I think that there must be a way to determine new devices with the 
bluetooth stack, so use the same mechanism as usb or pcmcia:

Register all found audio devices and create appropriate new cards in the 
ALSA driver. The application does not know, if it communicates with usb, 
bluetooth, PCI or ISA devices so passing some native information for the 
transport layer is not our goal.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01

Re: Other types of usb audio devices.

[James Courtier-Dutton]

Jaroslav Kysela wrote:
> On Sat, 5 Jul 2003, James Courtier-Dutton wrote:
> 
> 
>>Hi,
>>
>>The current snd-usb-audio driver assumes that the audio device is 
>>attached to this computer, so it only talks to this endpoint.
>>If I have an audio usb device with USB_CLASS = 0xe0, it will be a 
>>wireless device. I.E. A bluetooth headset.
>>It uses isoc's just like the current snd-usb-audio driver but adds some 
>>extra requirements, in order to open a connection, one needs to also 
>>know the bd address of the destination device  (Like a MAC address for 
>>ethernet) and keep tabs of connection number.
>>The current bluetooth stack I am using is bluez, from the current 2.4.20 
>>  kernel, and it uses network sockets for the audio. I would prefer to 
>>use alsa for sending and receiving audio to/from the headset, with all 
>>other control of the device going via the bluetooth stack.
>>So the question is: -
>>How do I get the bdaddr to alsa so that an application can use 
>>snd_pcm_open with the bluetooth headset, just as if it was a local audio 
>>card.
> 
> 
> I think that there must be a way to determine new devices with the 
> bluetooth stack, so use the same mechanism as usb or pcmcia:
> 
> Register all found audio devices and create appropriate new cards in the 
> ALSA driver. The application does not know, if it communicates with usb, 
> bluetooth, PCI or ISA devices so passing some native information for the 
> transport layer is not our goal.
> 
> 						Jaroslav

Another approach would be to use some other tool outside alsa to enter 
the bdaddr, and just present a Playback and Capture PCM to alsa lib.
I was thinking that the "card" would be the bluetooth usb dongle, and 
the pcm's would dynamically appear and disappear as the user attaches 
different bluetooth devices (e.g. headset).

Does alsa allow for PCMs to appear and disappear?
E.g. Card appears but no pcms listed in /proc/asound/card0
User runs a tool (attach-bluetooth-pcm) what sorts out a pairing of 
bluetooth devices and then creates a PCM device in /proc/asound/card0
User changes devices, and has to re-run attach-bluetooth-pcm to remove 
the old PCM, and create a new one of the new device.
OR: -
Would a new "card" have to be created for each bluetooth headset?
Is alsa happy with dynamically adding and removing cards ?

Cheers
James



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01

Re: Other types of usb audio devices.

[Jaroslav Kysela]

On Sat, 5 Jul 2003, James Courtier-Dutton wrote:

> Jaroslav Kysela wrote:
> > On Sat, 5 Jul 2003, James Courtier-Dutton wrote:
> > 
> > 
> >>Hi,
> >>
> >>The current snd-usb-audio driver assumes that the audio device is 
> >>attached to this computer, so it only talks to this endpoint.
> >>If I have an audio usb device with USB_CLASS = 0xe0, it will be a 
> >>wireless device. I.E. A bluetooth headset.
> >>It uses isoc's just like the current snd-usb-audio driver but adds some 
> >>extra requirements, in order to open a connection, one needs to also 
> >>know the bd address of the destination device  (Like a MAC address for 
> >>ethernet) and keep tabs of connection number.
> >>The current bluetooth stack I am using is bluez, from the current 2.4.20 
> >>  kernel, and it uses network sockets for the audio. I would prefer to 
> >>use alsa for sending and receiving audio to/from the headset, with all 
> >>other control of the device going via the bluetooth stack.
> >>So the question is: -
> >>How do I get the bdaddr to alsa so that an application can use 
> >>snd_pcm_open with the bluetooth headset, just as if it was a local audio 
> >>card.
> > 
> > 
> > I think that there must be a way to determine new devices with the 
> > bluetooth stack, so use the same mechanism as usb or pcmcia:
> > 
> > Register all found audio devices and create appropriate new cards in the 
> > ALSA driver. The application does not know, if it communicates with usb, 
> > bluetooth, PCI or ISA devices so passing some native information for the 
> > transport layer is not our goal.
> > 
> > 						Jaroslav
> 
> Another approach would be to use some other tool outside alsa to enter 
> the bdaddr, and just present a Playback and Capture PCM to alsa lib.
> I was thinking that the "card" would be the bluetooth usb dongle, and 
> the pcm's would dynamically appear and disappear as the user attaches 
> different bluetooth devices (e.g. headset).
> 
> Does alsa allow for PCMs to appear and disappear?
> E.g. Card appears but no pcms listed in /proc/asound/card0
> User runs a tool (attach-bluetooth-pcm) what sorts out a pairing of 
> bluetooth devices and then creates a PCM device in /proc/asound/card0
> User changes devices, and has to re-run attach-bluetooth-pcm to remove 
> the old PCM, and create a new one of the new device.
> OR: -
> Would a new "card" have to be created for each bluetooth headset?
> Is alsa happy with dynamically adding and removing cards ?

I prefer the allocation of new card for each physical boxes, because it is
common behaviour and the bluetooth devices might have more PCM devices and 
/ or MIDI devices. It would be difficult to enumerate all devices which
belongs to one physical box. It was one of the major reason, why I
introduced the card/device model rather than device only model used in
OSS.

And, yes, you can add/remove PCM or ALSA cards on the fly (if you handle 
locking properly, of course).

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01

Re: Other types of usb audio devices.

[Takashi Iwai]

At Mon, 7 Jul 2003 12:39:38 +0200 (CEST),
Jaroslav wrote:
> 
> On Sat, 5 Jul 2003, James Courtier-Dutton wrote:
> 
> > Jaroslav Kysela wrote:
> > > On Sat, 5 Jul 2003, James Courtier-Dutton wrote:
> > > 
> > > 
> > >>Hi,
> > >>
> > >>The current snd-usb-audio driver assumes that the audio device is 
> > >>attached to this computer, so it only talks to this endpoint.
> > >>If I have an audio usb device with USB_CLASS = 0xe0, it will be a 
> > >>wireless device. I.E. A bluetooth headset.
> > >>It uses isoc's just like the current snd-usb-audio driver but adds some 
> > >>extra requirements, in order to open a connection, one needs to also 
> > >>know the bd address of the destination device  (Like a MAC address for 
> > >>ethernet) and keep tabs of connection number.
> > >>The current bluetooth stack I am using is bluez, from the current 2.4.20 
> > >>  kernel, and it uses network sockets for the audio. I would prefer to 
> > >>use alsa for sending and receiving audio to/from the headset, with all 
> > >>other control of the device going via the bluetooth stack.
> > >>So the question is: -
> > >>How do I get the bdaddr to alsa so that an application can use 
> > >>snd_pcm_open with the bluetooth headset, just as if it was a local audio 
> > >>card.
> > > 
> > > 
> > > I think that there must be a way to determine new devices with the 
> > > bluetooth stack, so use the same mechanism as usb or pcmcia:
> > > 
> > > Register all found audio devices and create appropriate new cards in the 
> > > ALSA driver. The application does not know, if it communicates with usb, 
> > > bluetooth, PCI or ISA devices so passing some native information for the 
> > > transport layer is not our goal.
> > > 
> > > 						Jaroslav
> > 
> > Another approach would be to use some other tool outside alsa to enter 
> > the bdaddr, and just present a Playback and Capture PCM to alsa lib.
> > I was thinking that the "card" would be the bluetooth usb dongle, and 
> > the pcm's would dynamically appear and disappear as the user attaches 
> > different bluetooth devices (e.g. headset).
> > 
> > Does alsa allow for PCMs to appear and disappear?
> > E.g. Card appears but no pcms listed in /proc/asound/card0
> > User runs a tool (attach-bluetooth-pcm) what sorts out a pairing of 
> > bluetooth devices and then creates a PCM device in /proc/asound/card0
> > User changes devices, and has to re-run attach-bluetooth-pcm to remove 
> > the old PCM, and create a new one of the new device.
> > OR: -
> > Would a new "card" have to be created for each bluetooth headset?
> > Is alsa happy with dynamically adding and removing cards ?
> 
> I prefer the allocation of new card for each physical boxes, because it is
> common behaviour and the bluetooth devices might have more PCM devices and 
> / or MIDI devices. It would be difficult to enumerate all devices which
> belongs to one physical box. It was one of the major reason, why I
> introduced the card/device model rather than device only model used in
> OSS.
 
agreed.

in the case of usb audio/midi devices, a card instance is created for
each different usb device id (more exactly, the usb_device pointer).
this makes clear difference if you connect two different devices with
multi-pcm streams.

> And, yes, you can add/remove PCM or ALSA cards on the fly (if you handle 
> locking properly, of course).

yep.  for example, snd-usb-audio manages the creation/deleteion of
card instances on the fly.  also, ALSA pcmcia drivers create PCM/mixer
devices dynamically after the firmware is loaded by a user-space
tool.


i see the following scenario:

if the hotplug (or whatever a manager) can know the connection state
of bluetooth devices, it can invoke a script to notify the connection
/ disconnection to the ALSA driver.  then the driver wil create/delete
a corresponding card instance.

the question is how to tell the bd addr to the driver.
i think the bd addr can be given via hwdep device or via the control
API with a certain control.  the detailed implemention can be hidden
inside the alsa-lib like emu10k1's pcm set-up.


Takashi


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01