2010/6/20 David Dillow dave@thedillows.org
Please keep me on the cc list, I'll see your message sooner in my Inbox than my mailing list folders.
On Sun, 2010-06-20 at 08:20 +0200, Hans Schou wrote:
On Sat, 2010-06-19 at 16:13 +0200, Hans Schou wrote:
Hi
I have a problem with recording sound when using the sound chip SIS7019 with both kernel 2.6.26 and 2.6.34. After recording about 42 minutes it kind a stops recording, more precisely it is taking a pause of exactly 10 seconds between each reading.
As recorder I have tried several programs and all of them fails after 42 minutes. Some programs uses Alsa and some uses the old deprecated method. In this example I have logged sox rec.
Recording method in a script: strace -tt -o strace.log rec -c 1 -r 44100 -2 sox.wav & sleep 3000 kill $?
I think the answer is no, but to be sure -- are you talking directly to the hardware device, or are you going through pulseaudio?
Eh? No to what? Alsa?
Pulseaudio.
what is the default device ? dsnoop, hw or pulse
Please use alsa "hw" device first , and then pulseaudio
if you are using pulseaudio , you need to provide a full pulseaudio.log ( pulseaudio -vvvvv ) and cc PA developer with your result
I am not really sure. In strace I can see 'rec' uses ioclt which could implies that it is talking directly to hardware.
Probably, but I'm not familiar enough with the library/user-space side of alsa to know how it talks to plugins. I expect you are correct, though.
While rec is running, can you capture the configuration using head -1000 /proc/asound/card0/pcm0c/sub0/*
Below was captured while running: arecord -c 1 -r 44100 -f S16 arec01.wav
Please specify -D hw:0,0 and -v to get output of snd_pcm_dump()
You caught the correct files, yes. Did that command produce 10 second pauses? If not, then I need to see the same information from the rec command you were using to reproduce the issue before. It may be easier to just run the rec command for a moment to collect the data rather than wait the 40+ minutes to see if arecord also demonstrates the issue.
I got a strange error message from arecord while recording at rate 44100: overrun!!! (at least 0.188 ms long) overrun!!! (at least 0.190 ms long) overrun!!! (at least 0.191 ms long)
Could this be a clue?
Are you getting this result when using "hw" device or "pulse" device ?
what buffer size and period size are arecord using ?
Perhaps; I'm guessing that rec (sox) is using the mmap interface, and I've not done much with that -- though perhaps there is a bug in sox's overrun handling. You could enable SND_PCM_XRUN_DEBUG to see if overruns are happening when sox starts taking 10 seconds.
Getting overruns on SiS 550 based devices isn't entirely surprising, as it doesn't have a huge amount of horsepower or memory. If you have too much going on in the background, it is very easy to not have enough time to processes all of the captured data, especially if you are running short period/buffer sizes.
The error does occur with rate 8000 8bit (the default).
Do you mean 'does not occur'? That may be more expected -- 8khz/8bit has approximately 9% of the data as 44.1khz/16bit.
Can you try using arecord? You can use options to tell it how to configure the PCM. Especially interesting will be to configure 2
periods
per buffer vs whatever rec uses. 2 periods per buffer uses the hardware interrupts to clock out periods, where as 3+ uses a more complex mechanism. You can also use -M to use mmap vs not.
Options like this? strace -tt -o arec.log arecord -c 1 -r 44100 -f S16 -M arec.wav
AFAIK , pulse device did not support MMAP
Yes, for testing if the mmap interface is the problem. You can also use -v to have it print more information, including the source of the data (hw vs Pulseaudio). To check 1 period vs 2, you can use the --period-size/--buffer-size options. I seem to recall that there is a bug lurking around there somewhere, so you should check that you got 1 period using -v or the proc files. You may have to fallback to the -F/-B options and convert samples to microseconds.
Dave