Tiny Core Linux
Tiny Core Base => Raspberry Pi => Topic started by: vatte on February 17, 2016, 02:42:05 AM
-
Sound on PiCore 7.0 and a Raspberry Pi B+ fails with USB sound cards after around 6 hours of playback. It gets "stuck", repeating a buffer over and over again. This does not happen with the internal sound card or a HifiBerry AMP+. Also, the latest Raspbian does not seem to be affected.
This happens on a fresh install with only alsa.tcz and mpg123.tcz from the repositories, when looping an mp3 file with the command "mpg123 --loop -1 file.mp3". I first noticed this problem when playing a wav file with pyalsaaudio, but verified with mpg123 that it does not seem to have anything to do with my script.
Any suggestions? Is the USB sound card driver in Raspbian different from the one in TinyCore?
P.S. I've tested with these two common sound cards which both suffer from the bug:
USB Sound Card 1 on Amazon (http://www.amazon.co.uk/Dynamode-USB-Sound-Card-7/dp/B004FE6UCE/)
USB Sound Card 2 on Amazon (http://www.amazon.co.uk/SODIAL-Stereo-Adaptor-Windows-Compatible/dp/B008KGL2L2/)
-
Further testing revealed that the same thing does happen in Raspbian Jessie (updated with only mpg123 package installed). I will move the question also to the Raspberry Pi forums, to see if someone can test and verify the problem there. The problem is a bit difficult to test, as I have to wait ~6 hours before the sound fails.
I also noticed that dmesg has some of these messages in both Raspbian and PiCore, but I don't know what they mean:
usb 1-1.4: 1:1: cannot get freq at ep 0x5
-
USB Power problem ??
Tried to use the max_usb_current=1 in config.txt ??
-
Was it a system hang or just the usb card? Often a full hang can cause looping sound.
-
I've now confirmed that this bug also happens with Zoom H1 used as a USB sound card. I wonder if all USB sound cards are affected? Easy way to test this: start with a fresh install of piCore 7.0, install alsa, alsa-config and mpg123 from tce, download an mp3 file on the pi and run mpg123 --loop -1 file.mp3. After several hours (~6-7) the sound hangs for me.
USB Power problem ??
Tried to use the max_usb_current=1 in config.txt ??
Thanks, I just started a test with this enabled, I'll let you know the result.
Was it a system hang or just the usb card? Often a full hang can cause looping sound.
Definitely not a system hang. In fact I haven't found any logs that would show the sound hanging: The system and audio player software keeps running as if nothing happened. If I close the audio player software the sound stops, and when I run it again it starts playing the sound normally again.
-
It can be an mpg123 bug.
-
It can be an mpg123 bug.
I guess it's possible, but unlikely. It doesn't happen with built-in sound + mpg123, and does happen with USB sound and my own script using python+pyalsaaudio. I can do a next test (after usb current fix) with another audio player software that can loop files.
-
Hi vatte
Does this only happen when looping on one file or does it also happen after 6 to 7 hours of normal play?
-
Hi Rich,
Do you mean by normal play to play for example a playlist instead of looping one file?
I think the bug is directly related to one process opening the ALSA device and continuously playing sound to it for a long time. Closing the old process and starting a new one seems to restart this 6 hour time, as well as keeping the process open but stopping writes to the ALSA PCM device for several seconds and then resuming them.
I've currently solved it in my application by restarting the python script every 6 hours, but it seems like a hack rather than a real fix, especially as this problem only happens with USB sound cards, + restarting the script produces an audible gap in playback. I'm planning to use an I2S DAC now to have better reliability, but it's still interesting to know what is causing this problem.
max_usb_current=1
Thanks for the suggestion, but I'm afraid this didn't help, the sound crashed again.
-
Hi vatte
Do you mean by normal play to play for example a playlist instead of looping one file?
Yes.
-
Hi vatte
Do you mean by normal play to play for example a playlist instead of looping one file?
Yes.
Can you explain the reason behind this? I need to sometimes play the same file continuously for long periods of time as well. I can try it next, currently I'm testing the looping of one file with VLC instead of mpg123.
-
Hi vatte
Knowing the various ways to produce the fault will aid in finding the source of the problem. Personally I suspect a
subtle bug in mpg123. Possibly something along the line of a variable that unexpectedly wraps around to zero. Or
a signed integer that's being incremented and becomes negative when only positive values were expected.
I'm not really up on MP3s and audio encoding, but if you have a file that was encoded at a different sampling rate,
does it change how long it takes for the fault to appear?
-
VLC fails playback in a much shorter time and starts to produce white noise, but this might be completely unrelated.
I'm not convinced the bug is in mpg123. Currently it happens only with USB sound cards and in the same way with:
- mgp123 with mp3 file
- mpg321 with mp3 file
- python script that reads wav file and outputs to ALSA PCM device using pyalsaaudio, nothing to do with the above software
I'll do some more tests soon. If there's a certain software you'd like me to use, please let me know.
-
Hi vatte
I'm not convinced the bug is in mpg123. Currently it happens only with USB sound cards and in the same way with:
- mgp123 with mp3 file
- mpg321 with mp3 file
I did some checking and mpg321 is not a fork of mpg123 so they don't share a code base. Under PI they do both
depend on libasound.tcz under picore 6. Under picore 7 they also both depend on alsa-modules-4.1.13-piCore+.tcz.
VLC shares those same dependencies in the same way. So you may be right, it could be the library or modules.
-
Could it be some memory leak in the library or modules.
Can you do a script loop with some count down.
Maybe some temp files build up ?
Out of swap ?
Why not try to see what files are open with lsof.
And install strace, to trace and see what files are used.
Like:
strace -e trace=open mpg123 file.mp3
And the script like this.
#!/bin/bash
free -m
START=1
END=1000
for (( c=$START; c<=$END; c++ ))
do
mpg123 file.mp3
done
echo
echo "Boom!"
free -m
-
Hi patrikg
Closing the old process and starting a new one seems to restart this 6 hour time, as well as keeping the process open but stopping writes to the ALSA PCM device for several seconds and then resuming them.
I think that rules out a memory leak. Pausing the audio would not fix that.
Maybe some temp files build up ?
Out of swap ?
I don't think that's likely either for the same reason listed above.
The script wont work since it starts a new process after the previous one ends.
-
Hi vatte
Have you tried using the --reopen option?
From:
http://linux.die.net/man/1/mpg123
--reopen
Forces reopen of the audiodevice after ever song
-
Hi Rich,
Have you tried using the --reopen option?
I tried it (with the full command mpg123 --reopen --loop -1 file.mp3 but the bug still happened as usual. I haven't had time to test yet with a 6h+ playlist, but I'll try to get that done soon.
-
Is the mp3 file in ram ??
Or do you store the file in mmcblk0 and play the file.
Try to copy the file to ram first and then play.
-
Is the mp3 file in ram ??
Yes.
-
What i can see in my cmdline.txt there are some misspelling.
And have you tested to passed the parameter to the usb device to say that just doing usb 1.1.
Added the dwc_otg.speed=1 parameter to force USB to work only in full speed mode (speed of USB 1.1).
What i can se in my cmdline.txt there are picore 7.0.
c_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/ram0 elevator=d
eadline rootwait quiet nortc loglevel=3 noembed
There sould be dwc_otg.lpm_enable...not just c_otg.
Just google of this parameters, get lots of performance/hanging problems with usb devices with raspberry pi.
Take a look at all this parameters
cd /sys/module/dwc_otg/parameters
ls
for i in $(ls);do echo $i----$(cat $i);done