On Wed, Mar 06, 2013 at 01:15:06PM -0800, chris hermansen wrote:
> Does this help?
Kind of, but it doesn't bring me much closer to understanding why this happens.
It would be nice if I could reproduce this.
This might not be relevant at all, but could you try to do this change on top
of v3 of the patch, reproduce the the bug and look at /var/log/kern.log?
diff --git a/sound/usb/clock.c b/sound/usb/clock.c
index 98c4e26..746ec9b 100644
--- a/sound/usb/clock.c
+++ b/sound/usb/clock.c
@@ -304,7 +304,7 @@ static int set_sample_rate_v2(struct snd_usb_audio *chip, int iface,
cur_rate = data[0] | (data[1] << 8) | (data[2] << 16) | (data[3] << 24);
if (cur_rate != rate) {
- snd_printd(KERN_WARNING
+ snd_printk(KERN_WARNING
"current rate %d is different from the runtime rate %d\n",
cur_rate, rate);
}
@@ -330,8 +330,21 @@ static int set_sample_rate_v2(struct snd_usb_audio *chip, int iface,
case USB_ID(0x0d8c, 0x0315): /* CM6632A */
case USB_ID(0x0d8c, 0x0319): /* CM6631A */
case USB_ID(0x200c, 0x1030): /* Reloop */
- usb_set_interface(dev, iface, 0);
- usb_set_interface(dev, iface, fmt->altsetting);
+ snd_printk(KERN_WARNING
+ "%d:%d: resetting device after change %d -> %d\n",
+ dev->devnum, iface, prev_rate, cur_rate);
+ err = usb_set_interface(dev, iface, 0);
+ if (err < 0) {
+ snd_printk(KERN_WARNING
+ "%d:%d:%d: cannot reset interface (%d)\n",
+ dev->devnum, iface, 0, err);
+ }
+ err = usb_set_interface(dev, iface, fmt->altsetting);
+ if (err < 0) {
+ snd_printk(KERN_WARNING
+ "%d:%d:%d: cannot set interface (%d)\n",
+ dev->devnum, iface, fmt->altsetting, err);
+ }
break;
}
}
There are multiple possible outcomes:
1) It fixes the issue. In that case the problem must be very timing
sensitive.
2) The first printk hits. Then the device lies about the current rate.
3) The second printk does not hit. Then the device the device lies about the
previous rate.
4) The reset operation fails. Unlikely, but I should probably have checked the
reported error code anyway.
5) No change. usb_set_interface() after setting sample rate is not always
enough, the device needs to be kicked even harder.
My guess is 5.
You should be able to get your kernel tree into that state by saving
http://article.gmane.org/gmane.linux.alsa.devel/106041 as
cm6631-workaround-v3.patch and doing something like
git stash
git checkout -b cm6631-v3-logging origin/master
git am -k cm6631-workaround-v3.patch
git apply <patch above>
git commit -a -m "Add logging"
Torstein
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
Alsa-user mailing list
Alsa-user@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-user
