At Thu, 6 Sep 2012 15:17:58 +0200, Markus Trippelsdorf wrote:
On 2012.09.06 at 15:08 +0200, Takashi Iwai wrote:
At Thu, 6 Sep 2012 11:43:48 +0200, Markus Trippelsdorf wrote:
On 2012.09.06 at 10:21 +0200, Takashi Iwai wrote:
At Thu, 06 Sep 2012 09:35:26 +0200, Takashi Iwai wrote:
In short, a patch like below may fix the issue (note: completely untested!)
No it doesn't, unfortunately...
OK, I start tracking down the problem a bit more deeply now.
The issue happens when the first two URBs are passed to retire_playback_urb(). These are URBs filled before start_endpoints() are set, so they contain actually zero size. Even though these are a sort of dummy packets, the driver still tries to check with the queued delay account, and gives bogus errors.
So, essentially the messages are harmless and nothing to worry too much, but surely it doesn't look sexy.
The patch below should fix the problem. Please give it a try.
Yes, your patch finally fixes the problem. Thank you Takashi-san.
Thanks for your quick test!
If Daniel has no objection with that patch, I'm going to merge it.
Takashi
On 06.09.2012 16:31, Takashi Iwai wrote:
At Thu, 6 Sep 2012 15:17:58 +0200, Markus Trippelsdorf wrote:
On 2012.09.06 at 15:08 +0200, Takashi Iwai wrote:
At Thu, 6 Sep 2012 11:43:48 +0200, Markus Trippelsdorf wrote:
On 2012.09.06 at 10:21 +0200, Takashi Iwai wrote:
At Thu, 06 Sep 2012 09:35:26 +0200, Takashi Iwai wrote:
In short, a patch like below may fix the issue (note: completely untested!)
No it doesn't, unfortunately...
OK, I start tracking down the problem a bit more deeply now.
The issue happens when the first two URBs are passed to retire_playback_urb(). These are URBs filled before start_endpoints() are set, so they contain actually zero size. Even though these are a sort of dummy packets, the driver still tries to check with the queued delay account, and gives bogus errors.
So, essentially the messages are harmless and nothing to worry too much, but surely it doesn't look sexy.
The patch below should fix the problem. Please give it a try.
Yes, your patch finally fixes the problem. Thank you Takashi-san.
Thanks for your quick test!
If Daniel has no objection with that patch, I'm going to merge it.
No objections from my side. I also gave it a quick test, and even though I never saw the problem Markus was seeing, I agree to your findings.
Many thanks, everyone :)
Daniel
Hi,
I can very well believe that bogus triggering of this spewing message is now fixed by your patch (thanks!), but:
I get the very same message here on OpenWrt's 3.10.24 (verified to be properly containing your patch!), when playing usb-audio on TL-WDR3600 MIPS via MPD mp3 streaming, *and then*:
Execute
modprobe zram num_devices=4
# Set disksize of 16MB for /dev/zram0 echo $((16*1024*1024)) > /sys/block/zram0/disksize
mkswap /dev/zram0
# For zram, use higher prio than for traditional swap devices. swapon -p 100 /dev/zram0
Executing these commands will cause the status/error message to loop again (when doing so manually, it's directly after having executed the swapon command).
IOW: messages did not appear, then mkswap, then infinite loop, then run mpd stop then they're gone again.
Sample:
[183532.990000] delay: estimated 240, actual 0 [183533.000000] delay: estimated 240, actual 0 [183533.010000] delay: estimated 432, actual 288 [183533.020000] delay: estimated 528, actual 288 [183533.020000] delay: estimated 528, actual 288 [183533.030000] delay: estimated 288, actual 48 [183533.040000] delay: estimated 288, actual 48 [183533.050000] delay: estimated 432, actual 288 [183533.050000] delay: estimated 576, actual 288 [183533.060000] delay: estimated 528, actual 288
My running theory is that that mkswap causes a rather insurmountable temporary lockup of relevant system processing resources, which causes audio handling to get out of lock-step, infinitely (*that* one really shouldn't happen, right!?), not to be resolved until finally playback gets stopped again.
That message is discussed at "MPD filling kern.log with "delay: estimated 0, actual xxx"" http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=15204 as well, but I don't know whether that one is pre- or post-patch ;) (as opposed to my case, which definitely is post-patch)
Note also that I'm experiencing rather weirdly crackling sound when using aplay /usr/share/sounds/alsa/Front_Center.wav , but only *every other time* that I'm executing this command. But in this aplay case this delay message does *not* get produced, so I suspect that that crackling is a different issue.
Wellll... perhaps not quite: snd-usb-audio param nrpacks=1 (as favourably mentioned by the URL above) does solve both the mkswap looping error and the aplay crackling (and solves arec crackling / echoes / corruption, too!). However I guess that nrpacks=1 is not something that you would want to have in an optimally performing system...
usb-audio running on a bus-powered USB2 hub connected to USB2 router port, with certain other devices producing activity (FTDI RS232, X10 lirc remote).
Hmmmm (any interesting thoughts?),
Andreas Mohr
-
Andreas Mohr -
Daniel Mack -
Takashi Iwai