On Mon, 2010-06-21 at 22:10 +0200, Hans Schou wrote:
2010/6/21 Hans Schou linux@schou.dk:
I have just started: arecord -B 1000000 -F 500000 -c 1 -r 44100 -f S16 -M -D hw:0,0 -v arec.wav
It gave a file size of 258822944 bytes. Almost 50 min: echo "258822944/(2*60*44100)" | bc -ql 48.90
This is the longest recording I have made on this hardware.
I have this running now:
- arecord -B 200000 -F 100000 -c 1 -r 44100 -f S16 -M -D hw:0,0 -v arec.wav
Ok, it seems something is definately funky with the driver in general, and gets worse when we're using more than 2 periods per buffer.
If I use:
strace -tt -T -o record.log arecord -f S16 -r 44100 -c 1 -d 3600 \ --buffer-size=32768 --period-size=16384 -v -t raw - > /dev/null
I don't have any overruns, nor does it go into the 10-second pause mode. I do see an odd alternating pattern of one period taking 1.4ms to capture, and the next taking 732ms. The period should be about 371ms, so the lumpyness of the timing is likely making it easier to hit overruns.
Then, using:
strace -tt -T -o record.log arecord -f S16 -r 44100 -c 1 -d 3600 \ --buffer-size=32768 --period-size=8192 -v -t raw - > /dev/null
I was able to push it into the 10-second pause failure mode, without hitting any overruns. Initially it has a similar alternating pattern of 0.6ms then 363ms capture times until it drops into a 10 second pause just after 42 minutes.
Now that I finally got my hardware going and can reproduce this, I'll dig into it over the next few evenings.
Thanks for the report and help narrowing down the focus area, Dave