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
--
GNU/Linux. It's not the software that's free, it's you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
