On Thu, Mar 14, 2013 at 10:13:17AM +0100, Torstein Hegge wrote:
> If we can find some other explanation for the 'cannot get freq' and the
> large negative rate you saw earlier, it might help to replace the
> if (cur_rate != prev_rate) {
> with
> if (rate != prev_rate) {
> so that we do the reset if the target rate is different from the
> previous rate, ignoring what the device thinks its current rate is.
I had another look at the logs. If we choose to selectively ignore the
'cannot get freq', the other problems occurred directly after a missing
reset due to the device not reporting the just set rate when reading
back the rate. I think this is worth trying.
diff --git a/sound/usb/clock.c b/sound/usb/clock.c
index 746ec9b..68e1ac3 100644
--- a/sound/usb/clock.c
+++ b/sound/usb/clock.c
@@ -311,7 +311,7 @@ static int set_sample_rate_v2(struct snd_usb_audio *chip, int iface,
/* Some devices doesn't respond to sample rate changes while the
* interface is active. */
- if (cur_rate != prev_rate) {
+ if (rate != prev_rate) {
switch (chip->usb_id) {
/* C-Media CM6610/CM6620/CM6631 */
case USB_ID(0x054c, 0x06cf): /* Sony */
Torstein
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Alsa-user mailing list
Alsa-user@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-user
