Summary: | ALSA multiple soundcard naming collision chaos | ||
---|---|---|---|
Product: | [Applications] kmix | Reporter: | howl |
Component: | general | Assignee: | Christian Esken <esken> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | michal.humpula, rvdb |
Priority: | VHI | ||
Version: | 4.4 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
See Also: | https://bugs.kde.org/show_bug.cgi?id=315289 | ||
Latest Commit: | Version Fixed In: | 4.13 |
Description
howl
2013-11-11 22:06:29 UTC
Well, keys are based also on "card number", like seen in the kmixrc. Here you see the name "Creative_X-Fi" AND device number "1": MasterMixer=ALSA::Creative_X-Fi:1 KMix builds the number "1" itself, to avoid issues on kernel soundcard reordering. "1" means, the first detected card with the name "Creative_X-Fi". So for your case there should be two cards: ALSA::HDA-Intel - HD-Audio Generic:1 ALSA::HDA-Intel - HD-Audio Generic:2 If there is a key collision then it is a bug. I do not find one, though. Are you able to debug, to find the root cause? Probably related ticket is bug 315289. Short summary of the current findings: - Key is properly built from ID: backend.getId() - cardNumber is taken from the card counter, and that one uses the NAME as a key (so we count per name) So far so good. This is exactly as anticipated, and alone it does not explain the issue. Any more information would be helpful. --- Internal work note follows: ------------------------------------------------------ Mixer::recreateId() is not well done: - It is called twice: DBUSWrapper and possiblyAddMixer() - It is called after setting up the Timers. In a very(!) theoretical setup they could trigger before the _id is properly set. - Some time ago I annotated it with "The current solution works but is very hacky" => Possibly refactor ID creation now fully in the backends. I found the cause. it is definitely 100% broken. ------------------------------------------ bool MixerToolBox::possiblyAddMixer(Mixer *mixer) { int newCardInstanceNum = 1 + s_mixerNums[mixer->getBaseName()]; // OUCH ^^^^ mixer->getBaseName() is always empty here. As the name is set in openIfValid() if ( mixer->openIfValid(newCardInstanceNum) ) { // ... s_mixerNums[mixer->getBaseName()] = newCardInstanceNum; // ^^^ Now mixer->getBaseName() is set ------------------------------------------ This means, every card gets an instanceNumber of 1. Only solution is to move teh full key generation in the backend (where it actually belogs). Hi Christian, Thanks for looking into this. I changed email so I didn't get the info in time. If you haven't work on it yet, I think I would be able to post a suggested fix to reviewboard. I am in the process of fixing it. Thanks for the feedback. Fixed, at least for built-in cards that the kernel always detects in the same order. Hotplugged or reordered cards still have some problems, e.g. if one has two cards called "USB". But this is not the issue in this ticket, thus considering the bug fixed. Should be fixed in KDE 4.13. I don't really understand why this bug is marked as fixed in 4.13. I'm running kmix 4.14.8 and can't still properly manage HD-Audio devices. Juste as the inital poster, I have two devices reported with identical names by the kernel but different ID (A bit weird in my opinion but that's the way it is): bash-4.3$ cat /proc/asound/cards 0 [Generic ]: HDA-Intel - HD-Audio Generic HD-Audio Generic at 0xfeb64000 irq 41 1 [Generic_1 ]: HDA-Intel - HD-Audio Generic HD-Audio Generic at 0xfeb60000 irq 16 2 [CameraVenu ]: USB-Audio - Vimicro USB 2.0 PC Camera (Venu Vimicro Vimicro USB 2.0 PC Camera (Venu at usb-0000:00:12.2-5, high speed Kmix still defaults to the first "HD-Audio Generic" device and never allows me to manage the second with "Generic_1" ID. The later does work with Alsa and I can make use of it with VLC or Skype, albeit with some manual configuration. |