S51 usb support

S51 usb support

[Matti Picus]

My X-FI Surround USB card is barely usable. pulseaudio will let me 
control the volume levels, alsa support cannot view any volume controls.

How can I contribute to better support for this card under alsa? I would 
like to get to the point where amixer can control the analog 
input/output volume levels.

I am a capable programmer, but know very little about alsa, where should 
I start?
Matti

Re: S51 usb support

[Daniel Mack]

On Sun, Oct 03, 2010 at 11:22:00PM +0200, Matti Picus wrote:
> My X-FI Surround USB card is barely usable. pulseaudio will let me 
> control the volume levels, alsa support cannot view any volume controls.

But audio streaming does work for you? I heard people reporting success
with this kind of hardware.

> How can I contribute to better support for this card under alsa? I would 
> like to get to the point where amixer can control the analog 
> input/output volume levels.

As for the volume controls, there are merely two ways how they can be
implemented on USB soundcards. One is as feature unit control, and the
other is a proprietary vendor specific USB request. You should start
having a look at the USB descriptors the devices exports (by running
"lsusb -v").

In case the card does not offer a standard way to control the volume
levels, you need to trace how the Windows driver does it by sniffing
the communication while performing this specific operation, either with
an USB hardware analyzer, or with a piece of software. There are some
projects aiming for this, but I can't give you any recommendation. Just
try some of these, maybe:

  http://www.google.com/search?q=windows+usb+traffic+sniffer

Once you found out how they do it in Windows, you can add device
specific mixer handlers, as they exist for other hardware. Have a look
at sound/usb/mixer_quirks.c.

Hope that helps,

Daniel

Re: S51 usb support

[Matti Picus]

On 10/04/2010 06:41 AM, Daniel Mack wrote:
> On Sun, Oct 03, 2010 at 11:22:00PM +0200, Matti Picus wrote:
>    
>> My X-FI Surround USB card is barely usable. pulseaudio will let me
>> control the volume levels, alsa support cannot view any volume controls.
>>      
> But audio streaming does work for you? I heard people reporting success
> with this kind of hardware.
>    
Yes, audio streaming works in aplay if I choose the hw:S51 device. I 
cannot find a convenient way to control the volume without firing up 
pavucontrol, "convenient" in this case means "for mpd run as root"
>> How can I contribute to better support for this card under alsa? I would
>> like to get to the point where amixer can control the analog
>> input/output volume levels.
>>      
> As for the volume controls, there are merely two ways how they can be
> implemented on USB soundcards. One is as feature unit control, and the
> other is a proprietary vendor specific USB request. You should start
> having a look at the USB descriptors the devices exports (by running
> "lsusb -v").
>
>    
OK, what should I be looking for? Here is a summary:
 >lsusb -v -s 002:006 |grep '\(\<i[^I]\)\|\(bDescriptorSubtype\)\|\(PCM\)'
   idVendor           0x041e Creative Technology, Ltd
   idProduct          0x3042
   iManufacturer           1 Creative Technology
   iProduct                2 SB X-Fi Surround 5.1
   iSerial                 3 000008NV
     iConfiguration          0
         bDescriptorSubtype      1 (HEADER)
         bDescriptorSubtype      2 (INPUT_TERMINAL)
         iChannelNames           0
         iTerminal               0
         bDescriptorSubtype      3 (OUTPUT_TERMINAL)
         iTerminal               0
         bDescriptorSubtype      2 (INPUT_TERMINAL)
         iChannelNames           0
         iTerminal               0
         bDescriptorSubtype      3 (OUTPUT_TERMINAL)
         iTerminal               0
         bDescriptorSubtype      3 (OUTPUT_TERMINAL)
         iTerminal               0
         bDescriptorSubtype      1 (AS_GENERAL)
         wFormatTag              1 PCM
         bDescriptorSubtype      2 (FORMAT_TYPE)
           bDescriptorSubtype      1 (EP_GENERAL)
         bDescriptorSubtype      1 (AS_GENERAL)
         wFormatTag              1 PCM
         bDescriptorSubtype      2 (FORMAT_TYPE)
           bDescriptorSubtype      1 (EP_GENERAL)
         bDescriptorSubtype      1 (AS_GENERAL)
         wFormatTag              1 PCM
         bDescriptorSubtype      2 (FORMAT_TYPE)
           bDescriptorSubtype      1 (EP_GENERAL)
         bDescriptorSubtype      1 (AS_GENERAL)
         wFormatTag              1 PCM
         bDescriptorSubtype      2 (FORMAT_TYPE)
           bDescriptorSubtype      1 (EP_GENERAL)
         bDescriptorSubtype      1 (AS_GENERAL)
         wFormatTag              1 PCM
         bDescriptorSubtype      2 (FORMAT_TYPE)
           bDescriptorSubtype      1 (EP_GENERAL)
         bDescriptorSubtype      1 (AS_GENERAL)
         wFormatTag              1 PCM
         bDescriptorSubtype      2 (FORMAT_TYPE)
           bDescriptorSubtype      1 (EP_GENERAL)
         bDescriptorSubtype      1 (AS_GENERAL)
         bDescriptorSubtype      2 (FORMAT_TYPE)
           bDescriptorSubtype      1 (EP_GENERAL)
         bDescriptorSubtype      1 (AS_GENERAL)
         bDescriptorSubtype      2 (FORMAT_TYPE)
           bDescriptorSubtype      1 (EP_GENERAL)
         bDescriptorSubtype      1 (AS_GENERAL)
         wFormatTag              1 PCM
         bDescriptorSubtype      2 (FORMAT_TYPE)
           bDescriptorSubtype      1 (EP_GENERAL)
         bDescriptorSubtype      1 (AS_GENERAL)
         wFormatTag              1 PCM
         bDescriptorSubtype      2 (FORMAT_TYPE)
           bDescriptorSubtype      1 (EP_GENERAL)
         bDescriptorSubtype      1 (AS_GENERAL)
         wFormatTag              1 PCM
         bDescriptorSubtype      2 (FORMAT_TYPE)
           bDescriptorSubtype      1 (EP_GENERAL)
         bDescriptorSubtype      1 (AS_GENERAL)
         wFormatTag              1 PCM
         bDescriptorSubtype      2 (FORMAT_TYPE)
           bDescriptorSubtype      1 (EP_GENERAL)


> In case the card does not offer a standard way to control the volume
> levels, you need to trace how the Windows driver does it by sniffing
> the communication while performing this specific operation, either with
> an USB hardware analyzer, or with a piece of software. There are some
> projects aiming for this, but I can't give you any recommendation. Just
> try some of these, maybe:
>
>    http://www.google.com/search?q=windows+usb+traffic+sniffer
>
> Once you found out how they do it in Windows, you can add device
> specific mixer handlers, as they exist for other hardware. Have a look
> at sound/usb/mixer_quirks.c.
>
> Hope that helps,
>
> Daniel
>
>    
The card must offer something close to a standard set of volume controls 
since pulseaudio can control the basic stereo volume sliders. I would be 
happy if amixer or even alsamixer would see just the analog stereo 
output and analog line-in input. Currently, pulseaudio can control the 
volume levels but alsa cannot, alsamixer simply shows no volume controls.

Any guidance you can give toward getting the volume controls recognized 
would be greatly appreciate.
Matti

Re: S51 usb support

[Daniel Mack]

On Mon, Oct 04, 2010 at 10:08:56PM +0200, Matti Picus wrote:
> On 10/04/2010 06:41 AM, Daniel Mack wrote:
> >As for the volume controls, there are merely two ways how they can be
> >implemented on USB soundcards. One is as feature unit control, and the
> >other is a proprietary vendor specific USB request. You should start
> >having a look at the USB descriptors the devices exports (by running
> >"lsusb -v").
> >
> OK, what should I be looking for? Here is a summary:

Normally, the volume would be controlled by a feature unit. Just post
the whole output of 'lsusb -v' to some pastebin website and post the
link.

> The card must offer something close to a standard set of volume
> controls since pulseaudio can control the basic stereo volume
> sliders. 

No. PulseAudio will do the volume control in software if there are no
hardware controls.

> I would be happy if amixer or even alsamixer would see just
> the analog stereo output and analog line-in input. Currently,
> pulseaudio can control the volume levels but alsa cannot, alsamixer
> simply shows no volume controls.

Yes, because the driver doesn't know about any volume controls. If you
manage to implement them, PA will also use them.

> Any guidance you can give toward getting the volume controls
> recognized would be greatly appreciate.

The best way is to sniff the USB communication when Windows sets the
volume, and add controls to the Linux driver and make it do the same
thing.


Daniel

Re: S51 usb support

[Matti Picus]

On 10/05/2010 09:38 AM, Daniel Mack wrote:
>
> Normally, the volume would be controlled by a feature unit. Just post
> the whole output of 'lsusb -v' to some pastebin website and post the
> link.
>
>    
http://pastebin.com/e8ZcX9TN
>
>
>> Any guidance you can give toward getting the volume controls
>> recognized would be greatly appreciate.
>>      
> The best way is to sniff the USB communication when Windows sets the
> volume
>    
Is there an example in the alsa source tree of some of this?
Matti

Re: S51 usb support

[Daniel Mack]

On Tue, Oct 05, 2010 at 09:11:58PM +0200, Matti Picus wrote:
> On 10/05/2010 09:38 AM, Daniel Mack wrote:
> >
> >Normally, the volume would be controlled by a feature unit. Just post
> >the whole output of 'lsusb -v' to some pastebin website and post the
> >link.
> >
> http://pastebin.com/e8ZcX9TN

Hmm, there is no feature unit in this dump, so the volume is most
probably set with an vendor-specific USB request. Unless the Windows
driver does something similar than PulseAudio and handles the volume
level control in software (iow, modify each sample before sending it to
the hardware) rather than setting any actual hardware volume level.

> >>Any guidance you can give toward getting the volume controls
> >>recognized would be greatly appreciate.
> >The best way is to sniff the USB communication when Windows sets the
> >volume
> Is there an example in the alsa source tree of some of this?

Of a sniff dump you mean? I doubt so, but once you manage to get one
with any of the software tools around or with a hardware analyzer, the
dump itself shouldn't be hard to understand. You just need to understand
the packet layout and where they store the actual volume information.

Once you got this information, feel free to share it, so we can figure
out a nice way of generating the same kind of messages from inside the
kernel driver.

Daniel

S51 usb support

[Mandar Joshi]

> Hmm, there is no feature unit in this dump, so the volume is most
> probably set with an vendor-specific USB request. Unless the Windows
> driver does something similar than PulseAudio and handles the volume
> level control in software (iow, modify each sample before sending it to
> the hardware) rather than setting any actual hardware volume level.

Daniel, you are right, Its the driver thing.
Feb 2009, I was dealing this the same issue and
James Courtier-Dutton from this list pointed out that the device has no
hardware based mixer controls which is why alsamixer does not find anything.
He suggested using SoftVol.

I've been using dmix and Softvol for volume control whenever I need it.
This is the ~/.asoundrc I use http://mndar.phpnet.us/usbxfi/files/asoundrc.log

The device has a volume knob. I had left the issue of the volume knob
alone until a few days back..

I was about the post this when I came across the query from Matti Picus.

This is how it works.
The volume knob sends an interrupt via endpoint 0x83 containing 0xC0
0x00 whenever it is
rotated clockwise,anti-clockwise or pressed.
After this a control message is sent to the device to retrieve which
of the 3 actions it was.
The control packet sent is 0xa1 0x85 0x00 0x00 0x00 0x00 0x04 0x00
We get a 1 byte response.
0x0F for anti-clockwise rotation. 0x0D for press and 0x10 for
clockwise rotation.

I've tested this using a simple kernel module to handle just the
volume knob and it works fine.
The quick little code I've written does the above, then sets a sysfs
attribute and sends a kobject_uevent.
Udev rules execute a command depending on the value of this sysfs
attribute. (Having some issues here but anyway...)

Since the volume is entirely a software thing, I figure this might be
a good way of letting userspace know about the volume knob.
Using softvol we can have a Master volume control and then we can use
a command like amixer in udev rules to change the volume.
Or since events are passed to HAL, something could be done there.

I do not know much about the usbaudio driver but does this seem like
something that can be done from within the usbaudio driver ?


-Mandar Joshi

Re: S51 usb support

[Mandar Joshi]

On Wed, Oct 20, 2010 at 8:30 PM, Mandar Joshi <emailmandar@gmail.com> wrote:

> This is how it works.
> The volume knob sends an interrupt via endpoint 0x83 containing 0xC0
> 0x00 whenever it is
> rotated clockwise,anti-clockwise or pressed.
> After this a control message is sent to the device to retrieve which
> of the 3 actions it was.
> The control packet sent is 0xa1 0x85 0x00 0x00 0x00 0x00 0x04 0x00
> We get a 1 byte response.
> 0x0F for anti-clockwise rotation. 0x0D for press and 0x10 for
> clockwise rotation.
>


Seems the functionality to handle the endpoint and retrieve the action
is already present in snd-usb-audio
Just had to add an entry specific to USB X-Fi to mixer_quirks.c
I tested this with alsa-driver 1.0.23. Compiled it with debug. You can
see the received code in /var/log/messages
0x0F for anticlockwise rotation. 0x0D for press and 0x10 for clockwise rotation

Of course since there is no hardware mixer, the volume won't change.
This received code needs to be communicated to userspace. Any Suggestions?

Here is the addition I've tested

diff -rupN alsa-driver-1.0.23.orig/alsa-kernel/usb/mixer_quirks.c
alsa-driver-1.0.23/alsa-kernel/usb/mixer_quirks.c
--- alsa-driver-1.0.23.orig/alsa-kernel/usb/mixer_quirks.c	2010-04-16
11:10:10.000000000 +0000
+++ alsa-driver-1.0.23/alsa-kernel/usb/mixer_quirks.c	2010-10-22
10:45:22.000000000 +0000
@@ -61,6 +61,7 @@ static const struct rc_config {
 	{ USB_ID(0x041e, 0x3020), 2, 1, 6, 6,  18, 0x0013 }, /* Audigy 2 NX  */
 	{ USB_ID(0x041e, 0x3040), 2, 2, 6, 6,  2,  0x6e91 }, /* Live! 24-bit */
 	{ USB_ID(0x041e, 0x3048), 2, 2, 6, 6,  2,  0x6e91 }, /* Toshiba SB0500 */
+	{ USB_ID(0x041e, 0x3042), 0, 1, 1, 1,  1,  0x000d }, /* Usb X-Fi */
 };

 static void snd_usb_soundblaster_remote_complete(struct urb *urb)
@@ -75,7 +76,7 @@ static void snd_usb_soundblaster_remote_
 	code = mixer->rc_buffer[rc->offset];
 	if (rc->length == 2)
 		code |= mixer->rc_buffer[rc->offset + 1] << 8;
-
+	snd_printd(KERN_DEBUG "remote code: %02X\n",code);
 	/* the Mute button actually changes the mixer control */
 	if (code == rc->mute_code)
 		snd_usb_mixer_notify_id(mixer, rc->mute_mixer_id);

Re: S51 usb support

[Mandar Joshi]

On Fri, Oct 22, 2010 at 5:14 AM, Mandar Joshi <emailmandar@gmail.com> wrote:

> Just had to add an entry specific to USB X-Fi to mixer_quirks.c
> I tested this with alsa-driver 1.0.23. Compiled it with debug. You can
> see the received code in /var/log/messages
> 0x0F for anticlockwise rotation. 0x0D for press and 0x10 for clockwise rotation
>
> Of course since there is no hardware mixer, the volume won't change.
> This received code needs to be communicated to userspace. Any Suggestions?
>
> Here is the addition I've tested
>
> diff -rupN alsa-driver-1.0.23.orig/alsa-kernel/usb/mixer_quirks.c
> alsa-driver-1.0.23/alsa-kernel/usb/mixer_quirks.c
> --- alsa-driver-1.0.23.orig/alsa-kernel/usb/mixer_quirks.c      2010-04-16
> 11:10:10.000000000 +0000
> +++ alsa-driver-1.0.23/alsa-kernel/usb/mixer_quirks.c   2010-10-22
> 10:45:22.000000000 +0000
> @@ -61,6 +61,7 @@ static const struct rc_config {
>        { USB_ID(0x041e, 0x3020), 2, 1, 6, 6,  18, 0x0013 }, /* Audigy 2 NX  */
>        { USB_ID(0x041e, 0x3040), 2, 2, 6, 6,  2,  0x6e91 }, /* Live! 24-bit */
>        { USB_ID(0x041e, 0x3048), 2, 2, 6, 6,  2,  0x6e91 }, /* Toshiba SB0500 */
> +       { USB_ID(0x041e, 0x3042), 0, 1, 1, 1,  1,  0x000d }, /* Usb X-Fi */
>  };
>
>  static void snd_usb_soundblaster_remote_complete(struct urb *urb)
> @@ -75,7 +76,7 @@ static void snd_usb_soundblaster_remote_
>        code = mixer->rc_buffer[rc->offset];
>        if (rc->length == 2)
>                code |= mixer->rc_buffer[rc->offset + 1] << 8;
> -
> +       snd_printd(KERN_DEBUG "remote code: %02X\n",code);
>        /* the Mute button actually changes the mixer control */
>        if (code == rc->mute_code)
>                snd_usb_mixer_notify_id(mixer, rc->mute_mixer_id);
>

This works fine with the alsa_usb driver in lirc.
The code is received is being handled by Creative USB IR receiver
devices config in /etc/lircd.conf
So just adding

{ USB_ID(0x041e, 0x3042), 0, 1, 1, 1,  1,  0x000d }, /* Usb X-Fi */

to mixer_quirks.c is enough to get the volume knob working with Lirc.

Should I submit a patch for that?

-Mandar Joshi