[pulseaudio-discuss] Two identical USB sound-cards - second card fails to load because card-name found in hashmap.

[Colin Guthrie]

'Twas brillig, and Tanu Kaskinen at 24/08/10 16:41 did gyre and gimble:
> The card name generation in module-udev-detect seems to be unchanged
> between 0.9.19 and git master, so this is most still broken. I wrote a
> fix, btw :) If you like it, please pull. Here's the "git request-pull"
> output:
> 
> The following changes since commit
> ef0c73cb9de92c1ea3c7c3e2fc2808dc87af5c7f:
>   Wim Taymans (1):
>         echo-cancel: take into account snapshot delay
> 
> are available in the git repository at:
> 
>   git://gitorious.org/~tanuk/pulseaudio/tanuk-clone.git master
> 
> Tanu Kaskinen (3):
>       module-alsa-card: New argument: namereg_fail.
>       module-udev-detect: When loading module-alsa-card, use
> namereg_fail=false.
>       alsa-sink: Get rid of a compiler warning regarding
> rewind_safeguard type.
> 
>  src/modules/alsa/alsa-sink.c        |    4 ++--
>  src/modules/alsa/module-alsa-card.c |   15 +++++++++++++++
>  src/modules/module-udev-detect.c    |    1 +
>  3 files changed, 18 insertions(+), 2 deletions(-)

Ahh OK, so namereg_fail in data was already there, you just exposed it
via an argument and then made the udev-detect use it.

I guess this is a viable alternative for the time being. Like I say I'm
not sure what other approach could be used* to make this any nicer, so
may as well commit it :D

Cheers

Col

* FWIW, one approach would be to maintain a (local) database of card
names that have duplicates. When we encounter a duplicate card name for
the first time, we may have to take destructive action (i.e. unload the
sink with the generic name, then reload it again with a more qualified
one - likely involving the USB port name too), before inserting the new
device.

Keeping track of these would be the job of udev-detect, but I'm not sure
how "worth it" it is.

Perhaps it would be better to just mung the names but always use a
different key name for lookups in the databases we keep for stream and
device volumes... it would mean that the two physical devices would
likely then only be able to have one volume control even if they are
exposed as two.... which is again, not very nice.

Damn you lazy USB manufacturers!

Col






-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]