Re: Solved Hercules RMX2

[Daniel Mack <zonque@gmail.com>]

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-next

> 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
> 
>