2010/6/20 David Dillow <dave@xxxxxxxxxxxxxx> > 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 > > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
