Hi Daniel,
On 16.04.2013 21:14, Daniel Schürmann wrote:
Thank you for the suggestion. If there is no other solution than increasing the timeout, IMHO the code is simpler if we just increase the timeout for all devices. This way we will automatically fix all other devices based on the same hardware.
How many are there? Can you come up with a list of VID/PID? I never heard of problems of that kind really.
OTOH, I can't think of any obvious reason how a longer timeout should cause any problem for other devices, but as a general concern, we like to keep quirks as specific to the device as possible.
The long timeout is only quired by the first write command and 1 s is already quite long. Do you have another idea how to fix this?
Fix the firmware :) I can't think of anything that take a full second inside such a device.
Do you have a Idea what the remaining error messages are about? I cannot see a misbehavior anyway.
Also firmware problems. You can ignore them for now.
Just read: https://www.kernel.org/doc/Documentation/SubmittingPatches Is the patch fine to send out?
Which one? Also, before sending it, run scripts/checkpatch.pl on it, which will point out obvious style issues.
Against which Kernel should I patch?
https://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/log/?h=for-ne...
Where should I send it?
To the alsa-devel ML, and take Takashi and Clemens in Cc: (both copied in this mail).
Thanks, Daniel
2013/4/16 Daniel Mack <zonque@gmail.com mailto:zonque@gmail.com>
On 16.04.2013 17:35, Gabriel M. Beddingfield wrote: > On 04/16/2013 08:12 AM, Daniel Schürmann wrote: >> Hi Gabriel, >> >> Thank you for your quick response. >> The patch against the alsa-kernel is also attached at >> https://bugs.launchpad.net/mixxx/+bug/1096687 and here: > > OK, I see now. FYI, most maintainers prefer that you submit patches > according to the guidelines in Documentation/SubmittingPatches. (I'm > not a maintainer, BTW...) > >> >> diff --git a/sound/usb/helper.c b/sound/usb/helper.c >> index c1db28f..e044804 100644 >> --- a/sound/usb/helper.c >> +++ b/sound/usb/helper.c >> @@ -23,6 +23,9 @@ >> #include "helper.h" >> #include "quirks.h" >> >> +/* Hercules RMX2 needs 1240 ms for setting the sample rate the first time */ >> +#define USB_MSG_TIMEOUT 1500 >> + >> /* >> * combine bytes and get an integer value >> */ >> @@ -93,7 +96,7 @@ int snd_usb_ctl_msg(struct usb_device *dev, unsigned int pipe, __u8 request, >> return -ENOMEM; >> } >> err = usb_control_msg(dev, pipe, request, requesttype, >> - value, index, buf, size, 1000); >> + value, index, buf, size, USB_MSG_TIMEOUT); >> if (size > 0) { >> memcpy(data, buf, size); >> kfree(buf); > > This changes the value for every USB audio device... not just the RMX2. > Daniel, is there a better way to do this? Yes, you can store an integer in struct snd_usb_audio (call it usb_msg_timeout or s.th.), initialize it to 1000 from snd_usb_audio_probe() and add a quirk to override that value in snd_usb_apply_boot_quirk(). Thanks, Daniel