USB Sound Device detection problem

USB Sound Device detection problem

[Doug Kingston]

I am doing some work setting up some radio data nodes that use USB
soundcard devices to attach to radios.  I am building a system with
two radios and two identical soundcard devices attached to a Raspberry
Pi running Raspbian.  The devices are discovered at boot time by the
hid-generic subsystem:

(see dmesg output below)

I am accessing the sound devices from Wine via the ALSA stack.  The
problem I have is that
the product string is identical for both devices and they show up
identically to the Windows app ("USB PnP Sound Device").  I need to
find a way to alter this string so that they are different.  If they
were processed by udev I might be able to do something there.

The options seem to be:
1) fix at kernel usb discovery
2) somehow fix in the ALSA library (snd_*)
3) fix in Wine (mmsys.drv / winealsa.drv/mmdevdrv.c
4) somewhere else?

And, we need to do this in a supportable fashion that does not break
existing users of this subsystem.

Do you have any suggestions?

Regards,
  -Doug-


winlink@acs-vara-cappark:~$ lsusb
Bus 004 Device 002: ID 8087:8000 Intel Corp.
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 8087:8008 Intel Corp.
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0d8c:013a C-Media Electronics, Inc.
Bus 001 Device 002: ID 0403:6015 Future Technology Devices
International, Ltd Bridge(I2C/SPI/UART/FIFO)
Bus 001 Device 004: ID 0d8c:013a C-Media Electronics, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

winlink@acs-vara-cappark:~$ amixer -c 2 info
Card hw:2 'Device'/'C-Media Electronics Inc. USB PnP Sound Device at
usb-0000:00:14.0-9, full speed'
  Mixer name : 'USB Mixer'
  Components : 'USB0d8c:013a'
  Controls      : 10
  Simple ctrls  : 3
winlink@acs-vara-cappark:~$ amixer -c 3 info
Card hw:3 'Device_1'/'C-Media Electronics Inc. USB PnP Sound Device at
usb-0000:00:14.0-10, full spee'
  Mixer name : 'USB Mixer'
  Components : 'USB0d8c:013a'
  Controls      : 10
  Simple ctrls  : 3
winlink@acs-vara-cappark:~$

dmesg output:

[    1.743798] usb 3-1: New USB device found, idVendor=8087,
idProduct=8008, bcdDevice= 0.04
[    1.743799] usb 3-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    1.743935] hub 3-1:1.0: USB hub found
[    1.744047] hub 3-1:1.0: 6 ports detected
[    1.759796] usb 4-1: New USB device found, idVendor=8087,
idProduct=8000, bcdDevice= 0.04
[    1.759799] usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    1.759921] hub 4-1:1.0: USB hub found
[    1.760055] hub 4-1:1.0: 8 ports detected
[    1.831425] usb 1-9: new full-speed USB device number 3 using xhci_hcd
[    2.020574] usb 1-9: New USB device found, idVendor=0d8c,
idProduct=013a, bcdDevice= 1.00
[    2.020576] usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    2.020577] usb 1-9: Product: USB PnP Sound Device
[    2.020577] usb 1-9: Manufacturer: C-Media Electronics Inc.
[    2.025323] hidraw: raw HID events driver (C) Jiri Kosina
[    2.027693] usbcore: registered new interface driver usbhid
[    2.027694] usbhid: USB HID core driver
[    2.028580] input: C-Media Electronics Inc.       USB PnP Sound
Device as /devices/pci0000:00/0000:00:14.0/usb1/1-9/1-9:1.3/0003:0D8C:013A.0001/input/input3
[    2.087471] hid-generic 0003:0D8C:013A.0001: input,hidraw0: USB HID
v1.00 Device [C-Media Electronics Inc.       USB PnP Sound Device] on
usb-0000:00:14.0-9/input3
[    2.171437] usb 1-10: new full-speed USB device number 4 using xhci_hcd
[    2.288774] EXT4-fs (dm-0): mounted filesystem with ordered data
mode. Opts: (null)
[    2.299437] [drm] Cannot find any crtc or sizes
[    2.364637] usb 1-10: New USB device found, idVendor=0d8c,
idProduct=013a, bcdDevice= 1.00
[    2.364639] usb 1-10: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[    2.364641] usb 1-10: Product: USB PnP Sound Device
[    2.364641] usb 1-10: Manufacturer: C-Media Electronics Inc.
[    2.365761] input: C-Media Electronics Inc.       USB PnP Sound
Device as /devices/pci0000:00/0000:00:14.0/usb1/1-10/1-10:1.3/0003:0D8C:013A.0002/input/input4
[    2.423454] hid-generic 0003:0D8C:013A.0002: input,hidraw1: USB HID
v1.00 Device [C-Media Electronics Inc.       USB PnP Sound Device] on
usb-0000:00:14.0-10/input3

-Doug-

Re: USB Sound Device detection problem

[Greg KH]

On Tue, Jan 19, 2021 at 10:20:34AM -0800, Doug Kingston wrote:
> I am doing some work setting up some radio data nodes that use USB
> soundcard devices to attach to radios.  I am building a system with
> two radios and two identical soundcard devices attached to a Raspberry
> Pi running Raspbian.  The devices are discovered at boot time by the
> hid-generic subsystem:
> 
> (see dmesg output below)
> 
> I am accessing the sound devices from Wine via the ALSA stack.  The
> problem I have is that
> the product string is identical for both devices and they show up
> identically to the Windows app ("USB PnP Sound Device").  I need to
> find a way to alter this string so that they are different.  If they
> were processed by udev I might be able to do something there.

Why do you need the string to be changed?

And why can't you write a udev rule for this?

> The options seem to be:
> 1) fix at kernel usb discovery

Not going to change :)

> 2) somehow fix in the ALSA library (snd_*)
> 3) fix in Wine (mmsys.drv / winealsa.drv/mmdevdrv.c
> 4) somewhere else?

Why not trigger off of the topology of the USB device?  That's what
tools do today for multiple devices of the same exact type, which is
really common.  All of that can be done in userspace, with a udev rule,
or a script that is run when accessing a USB device by querying where in
the USB physical tree it is located.

> And, we need to do this in a supportable fashion that does not break
> existing users of this subsystem.

Userspace is the key, you have control over that, so why can't it detect
this?

thanks,

greg k-h

Re: USB Sound Device detection problem

[Alan Stern]

On Tue, Jan 19, 2021 at 10:20:34AM -0800, Doug Kingston wrote:
> I am doing some work setting up some radio data nodes that use USB
> soundcard devices to attach to radios.  I am building a system with
> two radios and two identical soundcard devices attached to a Raspberry
> Pi running Raspbian.  The devices are discovered at boot time by the
> hid-generic subsystem:
> 
> (see dmesg output below)
> 
> I am accessing the sound devices from Wine via the ALSA stack.  The
> problem I have is that
> the product string is identical for both devices and they show up
> identically to the Windows app ("USB PnP Sound Device").

Why is that bad?

Suppose instead of using a Raspberry Pi, you plugged these two sound 
cards into a desktop system that actually was running Windows.  How 
would they show up then?  How would the Windows app handle them?  
Whatever this turns out to be, Wine should be able to emulate it.

>  I need to
> find a way to alter this string so that they are different.

Why do the strings need to be different?  They wouldn't be different in 
the desktop-running-Windows case, would they?

>  If they
> were processed by udev I might be able to do something there.

They are processed by udev, but I have no idea whether Wine gets this 
information from udev or from somewhere else (such as directly from the 
sound cards themselves).

> The options seem to be:
> 1) fix at kernel usb discovery

As Greg said, the kernel isn't going to be changed to do this.  And even 
if you did change your own copy of the kernel, it wouldn't help if Wine 
gets the product strings directly from the sound cards.

> 2) somehow fix in the ALSA library (snd_*)

That might be feasible.  I don't know much about ALSA's internals.

> 3) fix in Wine (mmsys.drv / winealsa.drv/mmdevdrv.c

That also might work.  But in fact, I would expect Wine to handle these 
things the same way that native Windows does, whatever that is.  So if 
Windows doesn't alter the strings, most likely you shouldn't ask Wine to 
do so.

> 4) somewhere else?

How about in the app that uses the strings?

> And, we need to do this in a supportable fashion that does not break
> existing users of this subsystem.
> 
> Do you have any suggestions?

As Greg mentioned, the app could use the device ID numbers or other 
topology information to distinguish the two sound cards, even if the 
product strings are identical.

Alan Stern