[alsa-devel] A plea for help on mixer support for Fast Track Ultra (8R)
Hi,
I need some help again by someone who's more familiar with Alsa's inner working than I am. This might be you, Daniel ;-)
I've attached a patch series that would add support for the mixer in M-Audio's Fast Track Ultra (8R) devices.
BUT, it will break others!
It will break others in that mixer controls will show up multiple times. The reason for this seems to be my ambitiuos calling of snd_usb_create_mixer() for quirked devices in card.c. To circumvent the problem of a control showing up multiple times, I check for duplicates in add_unique_control_to_empty_mixer() and skip controls already present.
This doesn't work for devices which are not using add_unique_control_to_empty_mixer(), in other words *all* devices not using my messy patch...
So, probably the best thing would be to have some kind of entry in quirks-table.h to tell which device would need to be "mixerquirked" to prevent other devices to be disturbed. How can this be done?
I would highly appreciate anybody coming up with a proper solution.
Kind regards,
Felix
Sorry for the mail formated patches!
Here's a single combined patch.
Regards,
Felix
Am 18.05.2011 17:19, schrieb Felix Homann:
Hi,
I need some help again by someone who's more familiar with Alsa's inner working than I am. This might be you, Daniel ;-)
I've attached a patch series that would add support for the mixer in M-Audio's Fast Track Ultra (8R) devices.
BUT, it will break others!
It will break others in that mixer controls will show up multiple times. The reason for this seems to be my ambitiuos calling of snd_usb_create_mixer() for quirked devices in card.c. To circumvent the problem of a control showing up multiple times, I check for duplicates in add_unique_control_to_empty_mixer() and skip controls already present.
This doesn't work for devices which are not using add_unique_control_to_empty_mixer(), in other words *all* devices not using my messy patch...
So, probably the best thing would be to have some kind of entry in quirks-table.h to tell which device would need to be "mixerquirked" to prevent other devices to be disturbed. How can this be done?
I would highly appreciate anybody coming up with a proper solution.
Kind regards,
Felix
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
HI Felix,
On Wed, May 18, 2011 at 5:19 PM, Felix Homann linuxaudio@showlabor.de wrote:
I need some help again by someone who's more familiar with Alsa's inner working than I am. This might be you, Daniel ;-)
I've attached a patch series that would add support for the mixer in M-Audio's Fast Track Ultra (8R) devices.
BUT, it will break others!
It will break others in that mixer controls will show up multiple times. The reason for this seems to be my ambitiuos calling of snd_usb_create_mixer() for quirked devices in card.c. To circumvent the problem of a control showing up multiple times, I check for duplicates in add_unique_control_to_empty_mixer() and skip controls already present.
Hmm, I'm not sure whether I understand what you're trying to do. You want to add mixers that are not added by the generic driver? Then just have a look how this is done for other devices, like for example for the "Traktor Audio 10". Or do I miss your point?
As a general rule, let the check-patch.pl script that ships with the kernel have a look at your patches, it will point out obvious coding style issues and the like :)
Daniel
Hi Daniel,
Am 18.05.2011 19:51, schrieb Daniel Mack:
Hmm, I'm not sure whether I understand what you're trying to do. You want to add mixers that are not added by the generic driver?
I'm adding a mixer to a device that doesn't even tell the driver that a mixer is present. There's no descriptor for it whatsoever. Nevertheless, you can control the mixer just like a standard usb audio mixer. Therefore I wanted to reuse as much of already present code as possible. Most of all I didn't want to construct any URBs or write new control_get or _put functions.
The problem is not how to get the mixer for the Fast Track Ultra (FTU) working. The problem is how to do it without breaking other mixers ;-)
The main problem at the moment is that snd_usb_create_mixer() will not be called on quirked devices! Take a look at card.c: snd_usb_create_mixer() will only be called if snd_usb_create_quirk() returns > 0. But why should we assume that quirked devices don't have any mixers?
I have forced calling snd_usb_create_mixer() for every device in my patch set. But this way controls from other devices will show up multiple times. We definetely don't want that.
If snd_usb_create_mixer() will be called for the FTU then the rest of my patch set works just fine. So how can I tell card.c to call it? I think a generic solution would be best, like some entry in quirks-table.h.
As a general rule, let the check-patch.pl script that ships with the kernel have a look at your patches, it will point out obvious coding style issues and the like :)
I knew it wasn't ready for submission. After generating the patch I send I had already corrected the whitespaces and those lines with over 80 characters that weren't just copies from other locations. The remaining issues like "! cval" and "ERROR: do not use assignment in if condition" were all taken literally from other locations inside the respective files. So, besides one C99 comment it's very much in style with the files I've been working on ;-)
Regards,
Felix
On Wed, May 18, 2011 at 8:46 PM, Felix Homann linuxaudio@showlabor.de wrote:
Am 18.05.2011 19:51, schrieb Daniel Mack:
Hmm, I'm not sure whether I understand what you're trying to do. You want to add mixers that are not added by the generic driver?
I'm adding a mixer to a device that doesn't even tell the driver that a mixer is present. There's no descriptor for it whatsoever. Nevertheless, you can control the mixer just like a standard usb audio mixer. Therefore I wanted to reuse as much of already present code as possible. Most of all I didn't want to construct any URBs or write new control_get or _put functions.
Ok, I see your point. Well in that case, I would add the mixers in mixer_quirks.c just like you did in your patch, but I would basically copy some code from build_feature_ctl() and allocate and fill a special cval from within your quirk function. I would suggest making usb_feature_unit_ctl (the struct) public (remove the static, prefix the name with snd_usb_ and add the prototype to the header), so you can reference it from mixer_quirks.c. That way, you would keep all the _info, _get and _put functions privately to mixer.c, but still have the ability to reuse most of the code. You just need to fill your cval with data the generic functions can cope with. Does that make sense?
The problem is not how to get the mixer for the Fast Track Ultra (FTU) working. The problem is how to do it without breaking other mixers ;-)
You wouldn't alter any existing code that way, and just add special stuff for this device.
The main problem at the moment is that snd_usb_create_mixer() will not be called on quirked devices! Take a look at card.c: snd_usb_create_mixer() will only be called if snd_usb_create_quirk() returns > 0. But why should we assume that quirked devices don't have any mixers?
That is indeed strange, yes. I can't explain that. Not to break existing devices, I would suggest adding a bit-wise "flags" field to snd_usb_audio_quirk and still create the mixers if a certain flag (something like "QUIRK_FLAG_CREATE_STANDARD_MIXERS") is set. Clemens, Takashi, would that be ok?
In general, note that as long as functions are static, the can and should have short names. But once they're not, you're in the global kernel namespace, and all symbols must be well prefixed (with "snd_usb_" in that case) in order to avoid name collisions.
Daniel
Daniel,
The main problem at the moment is that snd_usb_create_mixer() will not be
called on quirked devices! Take a look at card.c: snd_usb_create_mixer() will only be called if snd_usb_create_quirk() returns > 0. But why should
we
assume that quirked devices don't have any mixers?
That is indeed strange, yes. I can't explain that. Not to break existing devices, I would suggest adding a bit-wise "flags" field to snd_usb_audio_quirk and still create the mixers if a certain flag (something like "QUIRK_FLAG_CREATE_STANDARD_MIXERS") is set. Clemens, Takashi, would that be ok?
In general, note that as long as functions are static, the can and should have short names. But once they're not, you're in the global kernel namespace, and all symbols must be well prefixed (with "snd_usb_" in that case) in order to avoid name collisions.
So this is probably a terrible idea but what about creating a new quirk
QUIRK_MIXER_STANDARD_INTERFACE and just having that eventually call snd_usb_create_mixer()
because conceptually I could see this as two problems with two solutions. one is that the interface type/blah is the mixer is a lie (vendor_specific instead of UAC2 MIXER . (should be solved via a "quirk" in quirk-table.h) and
The other is that the endpoint descriptors within that are wrong (solved in mixer_quirks)
or am I thinking about this wrong?
Grant.
At Wed, 18 May 2011 23:30:46 +0200, Daniel Mack wrote:
The main problem at the moment is that snd_usb_create_mixer() will not be called on quirked devices! Take a look at card.c: snd_usb_create_mixer() will only be called if snd_usb_create_quirk() returns > 0. But why should we assume that quirked devices don't have any mixers?
That is indeed strange, yes. I can't explain that. Not to break existing devices, I would suggest adding a bit-wise "flags" field to snd_usb_audio_quirk and still create the mixers if a certain flag (something like "QUIRK_FLAG_CREATE_STANDARD_MIXERS") is set. Clemens, Takashi, would that be ok?
Returning zero means that you don't follow any standard. In the comment of snd_usb_create_quirk: /* * audio-interface quirks * * returns zero if no standard audio/MIDI parsing is needed. * returns a positive value if standard audio/midi interfaces are parsed * after this. * returns a negative value at error. */
I see no big reason to make things more complex. If you want to avoid the standard audio parsing after quirk but only parse mixer, just call snd_usb_create_mixer() in your quirk function.
thanks,
Takashi
Am 19.05.2011 07:42, schrieb Takashi Iwai:
I see no big reason to make things more complex. If you want to avoid the standard audio parsing after quirk but only parse mixer, just call snd_usb_create_mixer() in your quirk function.
Maybe I'm misunderstanding your point. But I think your suggestion is making things more complex.
I don't want to avoid the standard audio parsing. I want to use standard quirks if possible and still would like a means to call snd_usb_create_mixer(). That's all.
The device in question can be handled by a standard quirks (QUIRK_ANY_INTERFACE, QUIRK_COMPOSITE, QUIRK_AUDIO_FIXED_ENDPOINT). There's no hook for calling snd_usb_create_mixer() by the respective quirk functions, is there? Should I really need not to use those standard quirks just to call snd_usb_create_mixer()?
Moreover, I can't believe that the Fast Track Ultra devices are the only ones in the world which have a standard USB mixer without exposing it through the descriptors. (I've often read something like "but the mixer won't work") A simple generic standard way to handle those devices would be nice to have.
Take a look at it from my perspective: I'm just a layman on all of this. I full heartedly confess, that I don't actually understand all those functions involved in making a mixer work. I don't understand usb control messages an so on. For example, take a look at the snd_nativeinstruments_control_put() function as Daniel suggested. There's a line
usb_control_msg(dev, usb_sndctrlpipe(dev, 0), bRequest, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT, cpu_to_le16(wValue), cpu_to_le16(wIndex), NULL, 0, 1000);
What is it? How is anyone not deeply involved with USB programming and/or audio device programming supposed to understand it? How is anybody supposed to help Alsa development to get his device working without deeply diving into all this stuff *which should not be needed*?
But being a layman I could still understand that the mixer unit in my device is there and that it is controlled by standard usb commands (control messages?). So what to do next?
For the capture, playback and MIDI side it's already simple: If you have a device that you suspect to be more or less standard compliant but just doesn't tell the world about it he can just try some combinations of QUIRK_AUDIO_FIXED_ENDPOINT, QUIRK_AUDIO_STANDARD_INTERFACE, QUIRK_MIDI_FIXED_ENDPOINT etc. (which by the way are still not easy to understand due to lack of documentation!).
For mixers, there isn't such a standard way. That's what I would like to have! And that's what I have at least sketched with my patch. (While the standard way to tell the driver to call snd_usb_create_mixer() is still missing.)
Take a look at my (maybe naive?) snd_ftu_controls_create() function. It's easy to understand, it's simple: I essentially just pass channel numbers, and names to build_named_mixer_unit_ctl() which is a slightly modified version of build_mixer_unit_ctl() and voila: I get a volume control for the respective mixer channel, just as if the control had been known from a descriptor. That's a lot easier to understand than fiddling around with usb_control_msg(), isn't it?
So, at the end as stated above, I would like to see a simple, easy to understand standard way to handle a mixer that essentially *is* a standard USB audio mixer but doesn't tell the world about it...And of course, it should work with my device ;-)
Kind regards,
Felix
Felix Homann wrote:
Am 19.05.2011 07:42, schrieb Takashi Iwai:
I see no big reason to make things more complex. If you want to avoid the standard audio parsing after quirk but only parse mixer, just call snd_usb_create_mixer() in your quirk function.
Maybe I'm misunderstanding your point. But I think your suggestion is making things more complex.
I don't want to avoid the standard audio parsing. I want to use standard quirks if possible and still would like a means to call snd_usb_create_mixer(). That's all.
The quirks-table.h framework handles only quirks that attach to a USB interface. So create a FTU mixer quirk for intf 0 (or a generic quirk with a separate table of mixer controls).
Moreover, I can't believe that the Fast Track Ultra devices are the only ones in the world which have a standard USB mixer without exposing it through the descriptors.
So far, they are the only ones where somebody bothered to find out what the controls are.
(Many vendor-specific controls don't implement the complex class- compliant mixer protocol.)
I knew it wasn't ready for submission. After generating the patch I send I had already corrected the whitespaces and those lines with over 80 characters that weren't just copies from other locations. The remaining issues like "! cval" and "ERROR: do not use assignment in if condition" were all taken literally from other locations inside the respective files.
"Do as I say, not as I do." ;-)
Regards, Clemens
At Thu, 19 May 2011 08:45:43 +0200, Felix Homann wrote:
Am 19.05.2011 07:42, schrieb Takashi Iwai:
I see no big reason to make things more complex. If you want to avoid the standard audio parsing after quirk but only parse mixer, just call snd_usb_create_mixer() in your quirk function.
Maybe I'm misunderstanding your point. But I think your suggestion is making things more complex.
I don't want to avoid the standard audio parsing. I want to use standard quirks if possible and still would like a means to call snd_usb_create_mixer(). That's all.
First off, there is no "standard" quirk per definition :) There can be common quirks used by multiple devices, but this doesn't justify the fact that it's no standard USB-audio.
In principle, quirks are provided to be self-contained. If it's not compliant to standard usb-audio, handle everything there -- that's the whole policy. If we add yet another condition here and there in the main path for specific devices, it'll make readability worse.
(Or, think like OO implementation: if you want to implement a variant, you wouldn't put new conditional branch, but usually override the necessary parts.)
In this particular case, you can call snd_usb_create_mixer() then create your mixer elements in addition in your quirk function. This is more straightforward than adding branches in multiple points.
Of course, there can be some room for refactoring to share codes between different quirks. But it's a thing to be done in quirk codes.
The device in question can be handled by a standard quirks (QUIRK_ANY_INTERFACE, QUIRK_COMPOSITE, QUIRK_AUDIO_FIXED_ENDPOINT). There's no hook for calling snd_usb_create_mixer() by the respective quirk functions, is there? Should I really need not to use those standard quirks just to call snd_usb_create_mixer()?
Moreover, I can't believe that the Fast Track Ultra devices are the only ones in the world which have a standard USB mixer without exposing it through the descriptors. (I've often read something like "but the mixer won't work") A simple generic standard way to handle those devices would be nice to have.
Take a look at it from my perspective: I'm just a layman on all of this. I full heartedly confess, that I don't actually understand all those functions involved in making a mixer work. I don't understand usb control messages an so on. For example, take a look at the snd_nativeinstruments_control_put() function as Daniel suggested. There's a line
usb_control_msg(dev, usb_sndctrlpipe(dev, 0), bRequest, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT, cpu_to_le16(wValue), cpu_to_le16(wIndex), NULL, 0, 1000);What is it? How is anyone not deeply involved with USB programming and/or audio device programming supposed to understand it? How is anybody supposed to help Alsa development to get his device working without deeply diving into all this stuff *which should not be needed*?
But being a layman I could still understand that the mixer unit in my device is there and that it is controlled by standard usb commands (control messages?). So what to do next?
For the capture, playback and MIDI side it's already simple: If you have a device that you suspect to be more or less standard compliant but just doesn't tell the world about it he can just try some combinations of QUIRK_AUDIO_FIXED_ENDPOINT, QUIRK_AUDIO_STANDARD_INTERFACE, QUIRK_MIDI_FIXED_ENDPOINT etc. (which by the way are still not easy to understand due to lack of documentation!).
For mixers, there isn't such a standard way. That's what I would like to have! And that's what I have at least sketched with my patch. (While the standard way to tell the driver to call snd_usb_create_mixer() is still missing.)
Take a look at my (maybe naive?) snd_ftu_controls_create() function. It's easy to understand, it's simple: I essentially just pass channel numbers, and names to build_named_mixer_unit_ctl() which is a slightly modified version of build_mixer_unit_ctl() and voila: I get a volume control for the respective mixer channel, just as if the control had been known from a descriptor. That's a lot easier to understand than fiddling around with usb_control_msg(), isn't it?
So, at the end as stated above, I would like to see a simple, easy to understand standard way to handle a mixer that essentially *is* a standard USB audio mixer but doesn't tell the world about it...And of course, it should work with my device ;-)
What I'm thinking is also to keep the thing simple. My points are: - Try to avoid conditional branches, don't touch the main path as much as possible - You can call the standard parsers in the quirk itself - You can create additional mixer contents in the quirk as well (so just use your simplified snd_ftu_controls_create()).
thanks,
Takashi
Please, Clemens, Daniel and Takashi.
Every single one of you knows at least one way of doing it correctly. I don't.
I don't understand most of your suggestions, I don't understand the whole quirk framework. I'm just a layman who knows one way of making the FTU mixer work which would break others (just by calling snd_usb_create_mixer() too many times).
The "blueprint patch" I've send is very small. It's just three functions, one of them is very simple the others are almost identical to already present functions.
So please, couldn't someone fill the gap between what I have found and a proper implementation? As I see it, you might easily spend the same amount of time explaining to me how it should be done or why my next proposed patch (which would probably take at least a couple of weeks) is not acceptable and so on. But this would probably run for weeks or even months.
Please, help.
Thanks,
Felix
Am 19.05.2011 09:24, schrieb Takashi Iwai:
In this particular case, you can call snd_usb_create_mixer() then create your mixer elements in addition in your quirk function. This is more straightforward than adding branches in multiple points.
Of course, there can be some room for refactoring to share codes between different quirks. But it's a thing to be done in quirk codes. What I'm thinking is also to keep the thing simple. My points are:
- Try to avoid conditional branches, don't touch the main path as much as possible
- You can call the standard parsers in the quirk itself
- You can create additional mixer contents in the quirk as well (so just use your simplified snd_ftu_controls_create()).
Am 19.05.2011 09:15, schrieb Clemens Ladisch:
So create a FTU mixer quirk for intf 0 (or a generic quirk with a separate table of mixer controls).
Am 18.05.2011 23:30, schrieb Daniel Mack:
Well in that case, I would add the mixers in mixer_quirks.c just like you did in your patch, but I would basically copy some code from build_feature_ctl() and allocate and fill a special cval from within your quirk function. I would suggest making usb_feature_unit_ctl (the struct) public (remove the static, prefix the name with snd_usb_ and add the prototype to the header), so you can reference it from mixer_quirks.c. That way, you would keep all the _info, _get and _put functions privately to mixer.c, but still have the ability to reuse most of the code. You just need to fill your cval with data the generic functions can cope with. Does that make sense?
On Thu, May 19, 2011 at 10:14 AM, Felix Homann linuxaudio@showlabor.de wrote:
Please, Clemens, Daniel and Takashi.
Every single one of you knows at least one way of doing it correctly. I don't.
I don't understand most of your suggestions, I don't understand the whole quirk framework. I'm just a layman who knows one way of making the FTU mixer work which would break others (just by calling snd_usb_create_mixer() too many times).
The "blueprint patch" I've send is very small. It's just three functions, one of them is very simple the others are almost identical to already present functions.
So please, couldn't someone fill the gap between what I have found and a proper implementation? As I see it, you might easily spend the same amount of time explaining to me how it should be done or why my next proposed patch (which would probably take at least a couple of weeks) is not acceptable and so on. But this would probably run for weeks or even months.
I'll have a look later. I was just under the impression you wanted to try yourself :)
Daniel
Great Daniel, thank you in advance!
I would really like to do it myself. It's just not a good time for me too dive further into the Alsa working. I wouldn't have brought the mixer thing up this time without being pushed again by Grant and some others. So I guess it's better for everybody to have the basic mixer controls in Alsa as soon as possible than to wait until I get it right ;-) Especially those with a FTU will appreciate that.
I'll probably have a bit more time from mid June to end of July, so maybe we can take a new look at the clicks then, if you still like to.
Thanks,
Felix
Am 19.05.2011 10:52, schrieb Daniel Mack:
I'll have a look later. I was just under the impression you wanted to try yourself :)
Daniel
On Thu, May 19, 2011 at 10:52 AM, Daniel Mack zonque@gmail.com wrote:
I'll have a look later. I was just under the impression you wanted to try yourself :)
Attached is a patch which should show how this could work. It won't be fully functional though, as there seems to be some sort of confusion in your patch. You're calling build_named_mixer_unit_ctl() with your loop variable "in_ch", but you ignore that value in the called function. That can't be intentional, can it?
Anyway, very little tweaking should be needed now to make this work, and if you send me back the modified patch, I'll split the work and post a patch set here.
Daniel
Hi Daniel,
Am 19.05.2011 13:05, schrieb Daniel Mack:
On Thu, May 19, 2011 at 10:52 AM, Daniel Mackzonque@gmail.com wrote:
I'll have a look later. I was just under the impression you wanted to try yourself :)
Attached is a patch which should show how this could work. It won't be fully functional though, as there seems to be some sort of confusion in your patch.
Thanks! I don't have the device here with me right now. I can try the patch in an hour or two !
You're calling build_named_mixer_unit_ctl() with your loop variable "in_ch", but you ignore that value in the called function. That can't be intentional, can it?
No, this isn't intentional. I wrote this in September, so I don't remember completely. But a glimpse at the code reveals that this is inherited from build_mixer_unit_ctl() which doesn't use the in_pin parameter either.
Back then I wanted both functions to be as closely related as possible, with the perspective to put them on a common base or let build_mixer_unit_ctl() actually call build_named_mixer_unit_ctl(). Most probably I later confused the in_pin parameter's (non-)meaning.
Anyway, very little tweaking should be needed now to make this work, and if you send me back the modified patch, I'll split the work and post a patch set here.
I'll send all the needed corrections.
Regards,
Felix
Hi Daniel,
if I haven't missed anything, snd_maudio_ftu_create_ctl() will not be called since snd_usb_create_mixer() will not be called on this device.
Regards,
Felix
Am 19.05.2011 13:05, schrieb Daniel Mack:
Attached is a patch which should show how this could work.
One more note:
You call snd_usb_create_mixer(mixer->chip, 0, 0) from snd_maudio_ftu_create_mixer() to create standard mixers first. There are no standard mixers on this device.
Regards,
Felix
On Thu, May 19, 2011 at 3:42 PM, Felix Homann linuxaudio@showlabor.de wrote:
One more note:
You call snd_usb_create_mixer(mixer->chip, 0, 0) from snd_maudio_ftu_create_mixer() to create standard mixers first. There are no standard mixers on this device.
Ah, fail. Ok, try this one.
Daniel
Am 19.05.2011 16:12, schrieb Daniel Mack:
Ah, fail. Ok, try this one.
Daniel
Hmm, this one crashes:
4104.824184] Modules linked in: snd_usb_audio(+) snd_usbmidi_lib snd_hrtimer binfmt_misc parport_pc ppdev dm_crypt vesafb snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_seq_midi snd_hwdep snd_rawmidi snd_pcm snd_seq_midi_event snd_seq snd_timer snd_seq_device fglrx(P) dcdbas snd psmouse soundcore serio_raw snd_page_alloc lp parport usbhid hid usb_storage firewire_ohci uas firewire_core crc_itu_t e1000e [ 4104.824220] [ 4104.824223] Pid: 3406, comm: modprobe Tainted: P 2.6.38-8-generic #42-Ubuntu Dell Inc. Dell DM061 /0WG864 [ 4104.824231] RIP: 0010:[<ffffffffa04b0119>] [<ffffffffa04b0119>] snd_usb_mixer_controls+0x49/0x1a0 [snd_usb_audio] [ 4104.824241] RSP: 0018:ffff88005eb3fb38 EFLAGS: 00010246 [ 4104.824243] RAX: 00000000041e3000 RBX: 0000000000000000 RCX: 0000000000000000 [ 4104.824246] RDX: ffff88008fcdbc28 RSI: 0000000000000000 RDI: ffff88005eb3fba0 [ 4104.824249] RBP: ffff88005eb3fbc8 R08: 0000000000000005 R09: ffff88008315b028 [ 4104.824251] R10: ffff88009b39acc8 R11: 0000000000016e50 R12: ffff88005eb3fb38 [ 4104.824254] R13: ffff8800922449e8 R14: 0000000000000000 R15: 0000000000000000 [ 4104.824258] FS: 00007f5c64217720(0000) GS:ffff8800bfc00000(0000) knlGS:0000000000000000 [ 4104.824261] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 4104.824263] CR2: 0000000000000020 CR3: 00000000652b5000 CR4: 00000000000006f0 [ 4104.824266] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4104.824269] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 4104.824272] Process modprobe (pid: 3406, threadinfo ffff88005eb3e000, task ffff88005d1116e0) [ 4104.824274] Stack: [ 4104.824276] ffff88008fcdbc28 ffff8800922449e8 0000000000000000 0000000000000000 [ 4104.824281] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 4104.824286] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 4104.824291] Call Trace: [ 4104.824303] [<ffffffffa03dd1b7>] ? snd_hidden_kzalloc+0x37/0x50 [snd] [ 4104.824312] [<ffffffffa04b065a>] snd_usb_create_mixer+0xba/0x2a0 [snd_usb_audio] [ 4104.824318] [<ffffffffa03dd1b7>] ? snd_hidden_kzalloc+0x37/0x50 [snd] [ 4104.824327] [<ffffffffa04b1dce>] create_standard_mixer_quirk+0x1e/0x20 [snd_usb_audio] [ 4104.824335] [<ffffffffa04b228d>] snd_usb_create_quirk+0x1d/0x50 [snd_usb_audio] [ 4104.824344] [<ffffffffa04b233e>] create_composite_quirk+0x7e/0xd0 [snd_usb_audio] [ 4104.824353] [<ffffffffa04b228d>] snd_usb_create_quirk+0x1d/0x50 [snd_usb_audio] [ 4104.824360] [<ffffffffa04ac686>] usb_audio_probe+0x146/0x8d0 [snd_usb_audio] [ 4104.824368] [<ffffffff8143e439>] usb_probe_interface+0x109/0x200 [ 4104.824373] [<ffffffff813ba858>] really_probe+0x68/0x190 [ 4104.824377] [<ffffffff813bab65>] driver_probe_device+0x45/0x70 [ 4104.824381] [<ffffffff813bac3b>] __driver_attach+0xab/0xb0 [ 4104.824385] [<ffffffff813bab90>] ? __driver_attach+0x0/0xb0 [ 4104.824389] [<ffffffff813b99de>] bus_for_each_dev+0x5e/0x90 [ 4104.824393] [<ffffffff813ba6ae>] driver_attach+0x1e/0x20 [ 4104.824396] [<ffffffff813ba215>] bus_add_driver+0xc5/0x280 [ 4104.824400] [<ffffffff813baed6>] driver_register+0x76/0x140 [ 4104.824405] [<ffffffff815c6e2d>] ? notifier_call_chain+0x4d/0x70 [ 4104.824409] [<ffffffff8143d008>] usb_register_driver+0xb8/0x170 [ 4104.824417] [<ffffffffa04cc000>] ? snd_usb_audio_init+0x0/0x1000 [snd_usb_audio] [ 4104.824424] [<ffffffffa04cc040>] snd_usb_audio_init+0x40/0x1000 [snd_usb_audio] [ 4104.824429] [<ffffffff81002175>] do_one_initcall+0x45/0x190 [ 4104.824435] [<ffffffff810a4feb>] sys_init_module+0xfb/0x250 [ 4104.824439] [<ffffffff8100c002>] system_call_fastpath+0x16/0x1b [ 4104.824442] Code: 4c 8d a5 70 ff ff ff 49 89 fd 4c 89 e7 48 8b 9a a0 00 00 00 f3 48 ab 48 89 95 70 ff ff ff 4c 89 ad 78 ff ff ff 8b 05 07 0c 01 00 <48> 8b 7b 20 8b 73 28 85 c0 48 89 7d 80 89 75 88 74 27 8b 4a 20 [ 4104.824482] RIP [<ffffffffa04b0119>] snd_usb_mixer_controls+0x49/0x1a0 [snd_usb_audio] [ 4104.824491] RSP <ffff88005eb3fb38> [ 4104.824493] CR2: 0000000000000020 [ 4104.824497] ---[ end trace b721d79c7e9b68a1 ]---
On Fri, May 20, 2011 at 12:12 PM, Felix Homann linuxaudio@showlabor.de wrote:
Hmm, this one crashes:
4104.824184] Modules linked in: snd_usb_audio(+) snd_usbmidi_lib
Could you send the first lines of the crash log, too?
Daniel
Sorry, here are the first lines:
[ 4104.510080] usb 1-3: new high speed USB device using ehci_hcd and address 2 [ 4104.661745] usb 1-3: config 1 interface 3 altsetting 0 bulk endpoint 0x7 has invalid maxpacket 8 [ 4104.661750] usb 1-3: config 1 interface 3 altsetting 0 bulk endpoint 0x87 has invalid maxpacket 8 [ 4104.824137] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [ 4104.824147] IP: [<ffffffffa04b0119>] snd_usb_mixer_controls+0x49/0x1a0 [snd_usb_audio] [ 4104.824170] PGD 652ba067 PUD 652d7067 PMD 0 [ 4104.824176] Oops: 0000 [#1] SMP [ 4104.824179] last sysfs file: /sys/module/snd_pcm/initstate [ 4104.824183] CPU 0
Am 20.05.2011 12:12, schrieb Felix Homann:
Am 19.05.2011 16:12, schrieb Daniel Mack:
Ah, fail. Ok, try this one.
Daniel
Hmm, this one crashes:
4104.824184] Modules linked in: snd_usb_audio(+) snd_usbmidi_lib snd_hrtimer binfmt_misc parport_pc ppdev dm_crypt vesafb snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_seq_midi snd_hwdep snd_rawmidi snd_pcm snd_seq_midi_event snd_seq snd_timer snd_seq_device fglrx(P) dcdbas snd psmouse soundcore serio_raw snd_page_alloc lp parport usbhid hid usb_storage firewire_ohci uas firewire_core crc_itu_t e1000e [ 4104.824220] [ 4104.824223] Pid: 3406, comm: modprobe Tainted: P 2.6.38-8-generic #42-Ubuntu Dell Inc. Dell DM061 /0WG864 [ 4104.824231] RIP: 0010:[<ffffffffa04b0119>] [<ffffffffa04b0119>] snd_usb_mixer_controls+0x49/0x1a0 [snd_usb_audio] [ 4104.824241] RSP: 0018:ffff88005eb3fb38 EFLAGS: 00010246 [ 4104.824243] RAX: 00000000041e3000 RBX: 0000000000000000 RCX: 0000000000000000 [ 4104.824246] RDX: ffff88008fcdbc28 RSI: 0000000000000000 RDI: ffff88005eb3fba0 [ 4104.824249] RBP: ffff88005eb3fbc8 R08: 0000000000000005 R09: ffff88008315b028 [ 4104.824251] R10: ffff88009b39acc8 R11: 0000000000016e50 R12: ffff88005eb3fb38 [ 4104.824254] R13: ffff8800922449e8 R14: 0000000000000000 R15: 0000000000000000 [ 4104.824258] FS: 00007f5c64217720(0000) GS:ffff8800bfc00000(0000) knlGS:0000000000000000 [ 4104.824261] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 4104.824263] CR2: 0000000000000020 CR3: 00000000652b5000 CR4: 00000000000006f0 [ 4104.824266] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4104.824269] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 4104.824272] Process modprobe (pid: 3406, threadinfo ffff88005eb3e000, task ffff88005d1116e0) [ 4104.824274] Stack: [ 4104.824276] ffff88008fcdbc28 ffff8800922449e8 0000000000000000 0000000000000000 [ 4104.824281] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 4104.824286] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 4104.824291] Call Trace: [ 4104.824303] [<ffffffffa03dd1b7>] ? snd_hidden_kzalloc+0x37/0x50 [snd] [ 4104.824312] [<ffffffffa04b065a>] snd_usb_create_mixer+0xba/0x2a0 [snd_usb_audio] [ 4104.824318] [<ffffffffa03dd1b7>] ? snd_hidden_kzalloc+0x37/0x50 [snd] [ 4104.824327] [<ffffffffa04b1dce>] create_standard_mixer_quirk+0x1e/0x20 [snd_usb_audio] [ 4104.824335] [<ffffffffa04b228d>] snd_usb_create_quirk+0x1d/0x50 [snd_usb_audio] [ 4104.824344] [<ffffffffa04b233e>] create_composite_quirk+0x7e/0xd0 [snd_usb_audio] [ 4104.824353] [<ffffffffa04b228d>] snd_usb_create_quirk+0x1d/0x50 [snd_usb_audio] [ 4104.824360] [<ffffffffa04ac686>] usb_audio_probe+0x146/0x8d0 [snd_usb_audio] [ 4104.824368] [<ffffffff8143e439>] usb_probe_interface+0x109/0x200 [ 4104.824373] [<ffffffff813ba858>] really_probe+0x68/0x190 [ 4104.824377] [<ffffffff813bab65>] driver_probe_device+0x45/0x70 [ 4104.824381] [<ffffffff813bac3b>] __driver_attach+0xab/0xb0 [ 4104.824385] [<ffffffff813bab90>] ? __driver_attach+0x0/0xb0 [ 4104.824389] [<ffffffff813b99de>] bus_for_each_dev+0x5e/0x90 [ 4104.824393] [<ffffffff813ba6ae>] driver_attach+0x1e/0x20 [ 4104.824396] [<ffffffff813ba215>] bus_add_driver+0xc5/0x280 [ 4104.824400] [<ffffffff813baed6>] driver_register+0x76/0x140 [ 4104.824405] [<ffffffff815c6e2d>] ? notifier_call_chain+0x4d/0x70 [ 4104.824409] [<ffffffff8143d008>] usb_register_driver+0xb8/0x170 [ 4104.824417] [<ffffffffa04cc000>] ? snd_usb_audio_init+0x0/0x1000 [snd_usb_audio] [ 4104.824424] [<ffffffffa04cc040>] snd_usb_audio_init+0x40/0x1000 [snd_usb_audio] [ 4104.824429] [<ffffffff81002175>] do_one_initcall+0x45/0x190 [ 4104.824435] [<ffffffff810a4feb>] sys_init_module+0xfb/0x250 [ 4104.824439] [<ffffffff8100c002>] system_call_fastpath+0x16/0x1b [ 4104.824442] Code: 4c 8d a5 70 ff ff ff 49 89 fd 4c 89 e7 48 8b 9a a0 00 00 00 f3 48 ab 48 89 95 70 ff ff ff 4c 89 ad 78 ff ff ff 8b 05 07 0c 01 00<48> 8b 7b 20 8b 73 28 85 c0 48 89 7d 80 89 75 88 74 27 8b 4a 20 [ 4104.824482] RIP [<ffffffffa04b0119>] snd_usb_mixer_controls+0x49/0x1a0 [snd_usb_audio] [ 4104.824491] RSP<ffff88005eb3fb38> [ 4104.824493] CR2: 0000000000000020 [ 4104.824497] ---[ end trace b721d79c7e9b68a1 ]---
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Fri, May 20, 2011 at 1:14 PM, Felix Homann linuxaudio@showlabor.de wrote:
Sorry, here are the first lines:
[ 4104.510080] usb 1-3: new high speed USB device using ehci_hcd and address 2 [ 4104.661745] usb 1-3: config 1 interface 3 altsetting 0 bulk endpoint 0x7 has invalid maxpacket 8 [ 4104.661750] usb 1-3: config 1 interface 3 altsetting 0 bulk endpoint 0x87 has invalid maxpacket 8 [ 4104.824137] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [ 4104.824147] IP: [<ffffffffa04b0119>] snd_usb_mixer_controls+0x49/0x1a0 [snd_usb_audio]
Ok, chip->ctrl_intf needs to be initialized. Next try ...
Daniel
so this works.. (ie compiles and I get controls that do change volumes of things )
I think there's something whacky with the control map. (I can't seem to send Ain5 to out 1 and 2 successfully. but I'll test this with felix's original code.
The Ain's are not capture volumes for this device.
There's 8 "analog ins" and 8 "software returns" (pcm channels) that are mixed to 8 outputs. all the input gain controls are physical or line +4db level balanced
Grant.
On Fri, May 20, 2011 at 9:37 PM, Daniel Mack zonque@gmail.com wrote:
On Fri, May 20, 2011 at 1:14 PM, Felix Homann linuxaudio@showlabor.de wrote:
Sorry, here are the first lines:
[ 4104.510080] usb 1-3: new high speed USB device using ehci_hcd and
address
2 [ 4104.661745] usb 1-3: config 1 interface 3 altsetting 0 bulk endpoint
0x7
has invalid maxpacket 8 [ 4104.661750] usb 1-3: config 1 interface 3 altsetting 0 bulk endpoint
0x87
has invalid maxpacket 8 [ 4104.824137] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [ 4104.824147] IP: [<ffffffffa04b0119>]
snd_usb_mixer_controls+0x49/0x1a0
[snd_usb_audio]
Ok, chip->ctrl_intf needs to be initialized. Next try ...
Daniel
So something is very whacky with the control map. not sure how to debug this.
The original patch felix posted works as I expect this one doesn't where should I start debugging this?
Grant.
On Sat, May 21, 2011 at 1:08 AM, Grant Diffey gdiffey@gmail.com wrote:
so this works.. (ie compiles and I get controls that do change volumes of things )
I think there's something whacky with the control map. (I can't seem to send Ain5 to out 1 and 2 successfully. but I'll test this with felix's original code.
The Ain's are not capture volumes for this device.
There's 8 "analog ins" and 8 "software returns" (pcm channels) that are mixed to 8 outputs. all the input gain controls are physical or line +4db level balanced
Grant.
On Fri, May 20, 2011 at 9:37 PM, Daniel Mack zonque@gmail.com wrote:
On Fri, May 20, 2011 at 1:14 PM, Felix Homann linuxaudio@showlabor.de wrote:
Sorry, here are the first lines:
[ 4104.510080] usb 1-3: new high speed USB device using ehci_hcd and
address
2 [ 4104.661745] usb 1-3: config 1 interface 3 altsetting 0 bulk endpoint
0x7
has invalid maxpacket 8 [ 4104.661750] usb 1-3: config 1 interface 3 altsetting 0 bulk endpoint
0x87
has invalid maxpacket 8 [ 4104.824137] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [ 4104.824147] IP: [<ffffffffa04b0119>]
snd_usb_mixer_controls+0x49/0x1a0
[snd_usb_audio]
Ok, chip->ctrl_intf needs to be initialized. Next try ...
Daniel
I'm not close to my FTU at the moment. So I can't test it myself. Could you try interchanging chn and n in the calls of snd_maudio_ftu_create_ctl(mixer, n, chn, name) in snd_maudio_ftu_create_mixer().
--Felix
Am 20.05.2011 17:43, schrieb Grant Diffey:
So something is very whacky with the control map. not sure how to debug this.
The original patch felix posted works as I expect this one doesn't where should I start debugging this?
Grant.
On Sat, May 21, 2011 at 1:08 AM, Grant Diffeygdiffey@gmail.com wrote:
so this works.. (ie compiles and I get controls that do change volumes of things )
I think there's something whacky with the control map. (I can't seem to send Ain5 to out 1 and 2 successfully. but I'll test this with felix's original code.
The Ain's are not capture volumes for this device.
There's 8 "analog ins" and 8 "software returns" (pcm channels) that are mixed to 8 outputs. all the input gain controls are physical or line +4db level balanced
Grant.
On Fri, May 20, 2011 at 9:37 PM, Daniel Mackzonque@gmail.com wrote:
On Fri, May 20, 2011 at 1:14 PM, Felix Homannlinuxaudio@showlabor.de wrote:
Sorry, here are the first lines:
[ 4104.510080] usb 1-3: new high speed USB device using ehci_hcd and
address
2 [ 4104.661745] usb 1-3: config 1 interface 3 altsetting 0 bulk endpoint
0x7
has invalid maxpacket 8 [ 4104.661750] usb 1-3: config 1 interface 3 altsetting 0 bulk endpoint
0x87
has invalid maxpacket 8 [ 4104.824137] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [ 4104.824147] IP: [<ffffffffa04b0119>]
snd_usb_mixer_controls+0x49/0x1a0
[snd_usb_audio]
Ok, chip->ctrl_intf needs to be initialized. Next try ...
Daniel
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Fri, May 20, 2011 at 5:43 PM, Grant Diffey gdiffey@gmail.com wrote:
So something is very whacky with the control map. not sure how to debug this.
The original patch felix posted works as I expect this one doesn't where should I start debugging this?
The first thing would be to define what you refer to with the term "wacky" :)
Does it fail creating the controls? Don't the control do what they're supposed to? Is the behaviour deterministic?
An easy way to track things in the driver is to add printk(KERN_WARNING ...); lines in the driver, then compile, unloaded and load the module again. Then find these lines in your syslog.
Daniel
So the controls are created as expected and do something but not everything I expect.
So my test setup here. is inputs on analog 1, 2 and 5 if I mute all the controls. that works.
but in no setting of the controls can I get channel 5 to output to 1 and 2. setting Ain5 -Out1 and Ain5-out2 does this on the earlier patch.
so even with all the controls at 100% (this should pass every input to every output simultaneously I can't hear the input on ch5 on the headphones.
I'm going to have to look at this tomorrow it's 2:30am here. night guys
Grant
On Sat, May 21, 2011 at 1:54 AM, Daniel Mack zonque@gmail.com wrote:
On Fri, May 20, 2011 at 5:43 PM, Grant Diffey gdiffey@gmail.com wrote:
So something is very whacky with the control map. not sure how to debug this.
The original patch felix posted works as I expect this one doesn't where should I start debugging this?
The first thing would be to define what you refer to with the term "wacky" :)
Does it fail creating the controls? Don't the control do what they're supposed to? Is the behaviour deterministic?
An easy way to track things in the driver is to add printk(KERN_WARNING ...); lines in the driver, then compile, unloaded and load the module again. Then find these lines in your syslog.
Daniel
On Fri, May 20, 2011 at 6:25 PM, Grant Diffey gdiffey@gmail.com wrote:
So the controls are created as expected and do something but not everything I expect.
So my test setup here. is inputs on analog 1, 2 and 5 if I mute all the controls. that works.
but in no setting of the controls can I get channel 5 to output to 1 and 2. setting Ain5 -Out1 and Ain5-out2 does this on the earlier patch.
so even with all the controls at 100% (this should pass every input to every output simultaneously I can't hear the input on ch5 on the headphones.
Ok, that sound like Felix can fix this as he wrote the original patch. Maybe something in my transition went wrong, but it's just much easier to figure out what's wrong with access to the hardware :)
Daniel
Hi all,
Am 20.05.2011 18:38, schrieb Daniel Mack:
Ok, that sound like Felix can fix this as he wrote the original patch. Maybe something in my transition went wrong, but it's just much easier to figure out what's wrong with access to the hardware :)
Yes, I guess that will be relatively easy to find. But please, don't expect anything before Monday.
Happy weekend,
Felix
I guess I found it, but can't verify at the moment:
chn should run from 1 to 16 in the for loop. If youo can't wait till Monday, please compare the for loop in Daniel's path with mine.
Again, have a nice weekend,
Felix
Hi again,
Am 20.05.2011 17:08, schrieb Grant Diffey:
I think there's something whacky with the control map. (I can't seem to send Ain5 to out 1 and 2 successfully. but I'll test this with felix's original code.
Grant, could you please try the attached patch. I haven't tested all 128 controls but it seems to work fine here. And while you're at it, could you please try some other "outs" as well. My FTU is in a rack and I can't easily access out 5-8.
The Ain's are not capture volumes for this device There's 8 "analog ins" and 8 "software returns" (pcm channels) that are mixed to 8 outputs. all the input gain controls are physical or line +4db level balanced
That's true. I abused the term "Capture Volume" for my purely personal interest, since it made navigating through the controls easier in alsamixer and alsamixer-qt4. So, Daniel and Takashi, please feel free to change the names to whatever you think is more appropriate.
Kind regards,
Felix
On Tue, May 24, 2011 at 12:11 PM, Felix Homann linuxaudio@showlabor.de wrote:
Hi again,
Am 20.05.2011 17:08, schrieb Grant Diffey:
I think there's something whacky with the control map. (I can't seem to send Ain5 to out 1 and 2 successfully. but I'll test this with felix's original code.
Grant, could you please try the attached patch. I haven't tested all 128 controls but it seems to work fine here. And while you're at it, could you please try some other "outs" as well. My FTU is in a rack and I can't easily access out 5-8.
Good. I already amended and split the patch into pieces and can send out the whole thing once you give me a go.
Daniel
At Tue, 24 May 2011 12:47:31 +0200, Daniel Mack wrote:
On Tue, May 24, 2011 at 12:11 PM, Felix Homann linuxaudio@showlabor.de wrote:
Hi again,
Am 20.05.2011 17:08, schrieb Grant Diffey:
I think there's something whacky with the control map. (I can't seem to send Ain5 to out 1 and 2 successfully. but I'll test this with felix's original code.
Grant, could you please try the attached patch. I haven't tested all 128 controls but it seems to work fine here. And while you're at it, could you please try some other "outs" as well. My FTU is in a rack and I can't easily access out 5-8.
Good. I already amended and split the patch into pieces and can send out the whole thing once you give me a go.
For putting the stuff into 2.6.40, please submit it until tomorrow, so that I can send a pull request in time. Linus announced that 2.6.40 has a shorter merge window.
thanks,
Takashi
Guys,
So I'm not going to get to this for ~10hrs which means missing the merge window nost likely for 2.6.40/2.8.0/3.0/whateverlinusdecidestocallit I'm comefortable with Felix having tested. I will get to it when I can but I'm currently @work and will be for 8hrs or so.
Grant.
On Tue, May 24, 2011 at 8:11 PM, Felix Homann linuxaudio@showlabor.dewrote:
Hi again,
Am 20.05.2011 17:08, schrieb Grant Diffey:
I think there's something whacky with the control map. (I can't seem to
send Ain5 to out 1 and 2 successfully. but I'll test this with felix's original code.
Grant, could you please try the attached patch. I haven't tested all 128 controls but it seems to work fine here. And while you're at it, could you please try some other "outs" as well. My FTU is in a rack and I can't easily access out 5-8.
The Ain's are not capture volumes for this device
There's 8 "analog ins" and 8 "software returns" (pcm channels) that are mixed to 8 outputs. all the input gain controls are physical or line +4db level balanced
That's true. I abused the term "Capture Volume" for my purely personal interest, since it made navigating through the controls easier in alsamixer and alsamixer-qt4. So, Daniel and Takashi, please feel free to change the names to whatever you think is more appropriate.
Kind regards,
Felix
participants (5)
-
Clemens Ladisch -
Daniel Mack -
Felix Homann -
Grant Diffey -
Takashi Iwai