PROBLEM: SIS7019 stops recording after 42 min
in [Kernel]
|
Prev: ~~Hi~~
Next: MMC: Add JZ4740 mmc driver
From: Hans Schou on 19 Jun 2010 10:20 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 $? Recording start 17:41:29 and undtil 18:23:38.977278 it writes about 6-7 times per second to disk. Then it begin only writing every 10 seconds. At this point it had written 27222 times to disk and the amount of data written so far is 28684288 bytes (including wav-header). WorkARound: When the recording stops, one can just exit 'rec' and start it again and record another 42 minutes. Reboot is not necessary. Apparently, the re-init of the sound chip fixes the problem. On other systems with nVidia CK804 or emu10k I do not have the same problem. I have looked at sound/pci/sis7019.c but I do not really know what I should look for. None of the numbers in my observations is in the power of 2 which I would expect it was. Like, I expected it stopped recording after 64MB or so, but that is not the case. Linux version 2.6.34-norhtec-sis (root(a)norh) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #7 Wed Jun 16 00:32:56 CEST 2010 (the kernel used was compiled on this system.) # scripts/ver_linux Gnu C 4.1.2 Gnu make 3.81 binutils 2.17 util-linux 2.12r mount 2.12r module-init-tools 3.3-pre2 e2fsprogs 1.40-WIP Linux C Library scripts/ver_linux: line 63: /proc/self/maps: No such file or directory Dynamic linker (ldd) 2.3.6 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.97 udev 105 # lspci -vvv 00:01.4 Multimedia audio controller: Silicon Integrated Systems [SiS] SiS7019 Audio Accelerator Subsystem: Silicon Integrated Systems [SiS] SiS7019 Audio Accelerator Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64 (500ns min, 6000ns max) Interrupt: pin B routed to IRQ 10 Region 0: I/O ports at dc00 [size=256] Region 1: Memory at dfff8000 (32-bit, non-prefetchable) [size=16K] Capabilities: [60] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: SiS7019 Kernel modules: snd-sis7019 Here is a snip from the log file when it goes from reading 7 times per second to every 10th second. Note two times "ioctl" within a second and then it goes over to a delay with 10 seconds between each "ioctl": 18:23:38.611877 ioctl(4, 0x800c4151, 0xbf96b1d0) = 0 18:23:38.784635 gettimeofday({1276446218, 785207}, NULL) = 0 18:23:38.786609 write(2, "\rTime: 42:08.19 [00:00.00] of 00:"..., 78)= 78 18:23:38.789354 write(3,"p\377q\377n\377k\377l\377p\377o\377o\377k\377n\377p\377q\377n\377o\377k\377l\377p"...,4096) = 4096 18:23:38.791590 write(3,"j\377l\377l\377j\377l\377k\377m\377k\377l\377n\377j\377l\377l\377n\377n\377g\377m"...,12288) = 12288 18:23:38.794425 gettimeofday({1276446218, 795024}, NULL) = 0 18:23:38.795762 ioctl(4, 0x800c4151, 0xbf96b1d0) = 0 18:23:38.970451 gettimeofday({1276446218, 971018}, NULL) = 0 18:23:38.972293 write(2, "\rTime: 42:08.37 [00:00.00] of 00:"..., 78)= 78 18:23:38.975134 write(3,"k\377m\377o\377k\377i\377j\377m\377o\377o\377m\377k\377m\377o\377k\377p\377n\377o"...,4096) = 4096 18:23:38.977278 write(3,"m\377j\377p\377n\377n\377r\377m\377o\377o\377o\377l\377h\377l\377l\377m\377o\377o"...,12288) = 12288 18:23:38.980176 gettimeofday({1276446218, 980773}, NULL) = 0 18:23:38.981516 ioctl(4, 0x800c4151, 0xbf96b1d0) = 0 18:23:48.983347 ioctl(4, 0x800c4151, 0xbf96b1d0) = 0 18:23:48.985710 gettimeofday({1276446228, 986317}, NULL) = 0 18:23:48.987784 write(2, "\rTime: 42:08.56 [00:00.00] of 00:"..., 78) = 78 18:23:48.990733 write(3,"j\377k\377l\377l\377l\377n\377l\377q\377q\377j\377l\377m\377m\377p\377o\377o\377q"...,4096) = 4096 18:23:48.992814 write(3,"p\377m\377k\377s\377r\377m\377o\377m\377k\377k\377j\377j\377l\377p\377o\377r\377l"...,12288) = 12288 18:23:48.995694 gettimeofday({1276446228, 996297}, NULL) = 0 18:23:48.997046 ioctl(4, 0x800c4151, 0xbf96b1d0) = 0 18:23:48.999574 gettimeofday({1276446229, 186}, NULL) = 0 18:23:49.003421 write(3,"l\377l\377m\377o\377q\377q\377n\377m\377q\377r\377s\377p\377n\377t\377r\377m\377n"...,4096) = 4096 18:23:49.005517 write(3,"o\377m\377l\377p\377m\377p\377o\377m\377p\377p\377q\377o\377j\377m\377r\377m\377r"...,12288) = 12288 18:23:49.008337 gettimeofday({1276446229, 8945}, NULL) = 0 18:23:49.009699 ioctl(4, 0x800c4151, 0xbf96b1d0) = 0 18:23:59.007878 ioctl(4, 0x800c4151, 0xbf96b1d0) = 0 Version of sox: SoX v14.0.1 Full log file is 780KB compressed: http://schou.dk/linux/sis7019/strace.sis7019.sox-rec.2010-06-13.log.bz2 Hardware system used is a Norhtec MicroClient Jr with SIS550 CPU: http://www.norhtec.com/products/mcjrmx/index.html best regards/hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Dillow on 19 Jun 2010 15:00 Not trimming for the benefit of alsa-devel, cc'd. Please trim replies. 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? While rec is running, can you capture the configuration using head -1000 /proc/asound/card0/pcm0c/sub0/* Once you have the information, there is no need to run it all the way out. I think that's the right path, but I'm going from memory so you may have to look around under /proc/asound. I'm trying to get my MicroClient up and running again so I can try to reproduce this. This information will help me narrow my focus to the correct area of the driver. 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. > Recording start 17:41:29 and undtil 18:23:38.977278 it writes about > 6-7 times per second to disk. Then it begin only writing every 10 > seconds. At this point it had written 27222 times to disk and the > amount of data written so far is 28684288 bytes (including > wav-header). > > WorkARound: When the recording stops, one can just exit 'rec' and > start it again and record another 42 minutes. Reboot is not necessary. > Apparently, the re-init of the sound chip fixes the problem. > > On other systems with nVidia CK804 or emu10k I do not have the same problem. > > I have looked at sound/pci/sis7019.c but I do not really know what I > should look for. None of the numbers in my observations is in the > power of 2 which I would expect it was. Like, I expected it stopped > recording after 64MB or so, but that is not the case. > > Linux version 2.6.34-norhtec-sis (root(a)norh) (gcc version 4.1.2 > 20061115 (prerelease) (Debian 4.1.1-21)) #7 Wed Jun 16 00:32:56 CEST > 2010 > (the kernel used was compiled on this system.) > > # scripts/ver_linux > Gnu C 4.1.2 > Gnu make 3.81 > binutils 2.17 > util-linux 2.12r > mount 2.12r > module-init-tools 3.3-pre2 > e2fsprogs 1.40-WIP > Linux C Library scripts/ver_linux: line 63: /proc/self/maps: No > such file or directory > Dynamic linker (ldd) 2.3.6 > Net-tools 1.60 > Console-tools 0.2.3 > Sh-utils 5.97 > udev 105 > > # lspci -vvv > 00:01.4 Multimedia audio controller: Silicon Integrated Systems [SiS] > SiS7019 Audio Accelerator > Subsystem: Silicon Integrated Systems [SiS] SiS7019 Audio > Accelerator > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- DisINTx- > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium > >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > Latency: 64 (500ns min, 6000ns max) > Interrupt: pin B routed to IRQ 10 > Region 0: I/O ports at dc00 [size=256] > Region 1: Memory at dfff8000 (32-bit, non-prefetchable) > [size=16K] > Capabilities: [60] Power Management version 2 > Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA > PME(D0+,D1+,D2+,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > Kernel driver in use: SiS7019 > Kernel modules: snd-sis7019 > > Here is a snip from the log file when it goes from reading 7 times per > second to every 10th second. Note two times "ioctl" within a second > and then it goes over to a delay with 10 seconds between each "ioctl": > > 18:23:38.611877 ioctl(4, 0x800c4151, 0xbf96b1d0) = 0 > 18:23:38.784635 gettimeofday({1276446218, 785207}, NULL) = 0 > 18:23:38.786609 write(2, "\rTime: 42:08.19 [00:00.00] of 00:"..., 78)= 78 > 18:23:38.789354 > write(3,"p\377q\377n\377k\377l\377p\377o\377o\377k\377n\377p\377q\377n\377o\377k\377l\377p"...,4096) > = 4096 > 18:23:38.791590 > write(3,"j\377l\377l\377j\377l\377k\377m\377k\377l\377n\377j\377l\377l\377n\377n\377g\377m"...,12288) > = 12288 > 18:23:38.794425 gettimeofday({1276446218, 795024}, NULL) = 0 > 18:23:38.795762 ioctl(4, 0x800c4151, 0xbf96b1d0) = 0 > 18:23:38.970451 gettimeofday({1276446218, 971018}, NULL) = 0 > 18:23:38.972293 write(2, "\rTime: 42:08.37 [00:00.00] of 00:"..., 78)= 78 > 18:23:38.975134 > write(3,"k\377m\377o\377k\377i\377j\377m\377o\377o\377m\377k\377m\377o\377k\377p\377n\377o"...,4096) > = 4096 > 18:23:38.977278 > write(3,"m\377j\377p\377n\377n\377r\377m\377o\377o\377o\377l\377h\377l\377l\377m\377o\377o"...,12288) > = 12288 > 18:23:38.980176 gettimeofday({1276446218, 980773}, NULL) = 0 > 18:23:38.981516 ioctl(4, 0x800c4151, 0xbf96b1d0) = 0 > 18:23:48.983347 ioctl(4, 0x800c4151, 0xbf96b1d0) = 0 > 18:23:48.985710 gettimeofday({1276446228, 986317}, NULL) = 0 > 18:23:48.987784 write(2, "\rTime: 42:08.56 [00:00.00] of 00:"..., 78) = 78 > 18:23:48.990733 > write(3,"j\377k\377l\377l\377l\377n\377l\377q\377q\377j\377l\377m\377m\377p\377o\377o\377q"...,4096) > = 4096 > 18:23:48.992814 > write(3,"p\377m\377k\377s\377r\377m\377o\377m\377k\377k\377j\377j\377l\377p\377o\377r\377l"...,12288) > = 12288 > 18:23:48.995694 gettimeofday({1276446228, 996297}, NULL) = 0 > 18:23:48.997046 ioctl(4, 0x800c4151, 0xbf96b1d0) = 0 > 18:23:48.999574 gettimeofday({1276446229, 186}, NULL) = 0 > 18:23:49.003421 > write(3,"l\377l\377m\377o\377q\377q\377n\377m\377q\377r\377s\377p\377n\377t\377r\377m\377n"...,4096) > = 4096 > 18:23:49.005517 > write(3,"o\377m\377l\377p\377m\377p\377o\377m\377p\377p\377q\377o\377j\377m\377r\377m\377r"...,12288) > = 12288 > 18:23:49.008337 gettimeofday({1276446229, 8945}, NULL) = 0 > 18:23:49.009699 ioctl(4, 0x800c4151, 0xbf96b1d0) = 0 > 18:23:59.007878 ioctl(4, 0x800c4151, 0xbf96b1d0) = 0 > > Version of sox: SoX v14.0.1 > > Full log file is 780KB compressed: > http://schou.dk/linux/sis7019/strace.sis7019.sox-rec.2010-06-13.log.bz2 > > Hardware system used is a Norhtec MicroClient Jr with SIS550 CPU: > http://www.norhtec.com/products/mcjrmx/index.html > > best regards/hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Hans Schou on 20 Jun 2010 02:30 2010/6/19 David Dillow <dave(a)thedillows.org>: > Not trimming for the benefit of alsa-devel, cc'd. Please trim replies. ok > 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? I am not really sure. In strace I can see 'rec' uses ioclt which could implies that it is talking directly to hardware. > 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 ==> /proc/asound/card0/pcm0c/sub0/hw_params <== access: RW_INTERLEAVED format: S16_LE subformat: STD channels: 1 rate: 44100 (44100/1) period_size: 5513 buffer_size: 22050 ==> /proc/asound/card0/pcm0c/sub0/info <== card: 0 device: 0 subdevice: 0 stream: CAPTURE id: SiS7019 name: SiS7019 subname: subdevice #0 class: 0 subclass: 0 subdevices_count: 1 subdevices_avail: 0 ==> /proc/asound/card0/pcm0c/sub0/prealloc <== 64 ==> /proc/asound/card0/pcm0c/sub0/prealloc_max <== 128 ==> /proc/asound/card0/pcm0c/sub0/status <== state: RUNNING owner_pid : 3112 trigger_time: 1277013037.939382815 tstamp : 1277013038.809174469 delay : 10640 avail : 10640 avail_max : 10920 ----- hw_ptr : 38368 appl_ptr : 27728 ==> /proc/asound/card0/pcm0c/sub0/sw_params <== tstamp_mode: NONE period_step: 1 avail_min: 5513 start_threshold: 1 stop_threshold: 22050 silence_threshold: 0 silence_size: 0 boundary: 1944986400 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? The error does occur with rate 8000 8bit (the default). > 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 best regards/hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Dillow on 20 Jun 2010 10:30 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. > 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 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? 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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Hans Schou on 21 Jun 2010 02:00
2010/6/20 David Dillow <dave(a)thedillows.org>: > 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. Over night I have been running arecord several times. Alle wav-files are much below the expected size 264600000 bytes (44100*2*60s*50min). The file size recorded 184928116 184939142 185170688 186030716 186989978 187166394 187221524 188555670 188654904 188798242 189503906 189900842 189900842/(44100*2*60) = 35.88 Only 35 minutes of recording but I was running in 50min. It seems that arecord loses more sample than I have seen with sox-rec. > 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. How do I enable SND_PCM_XRUN_DEBUG with sox? > Getting overruns on SiS 550 based devices isn't entirely surprising, as > it doesn't have a huge amount of horsepower or memory. Well, I usually don't have problem with that. I have samba running but I don't access the recorded files while recording, so it is not a problem. Right now uptime says load average: 0.19, 0.21, 0.18 but strace and top is the bad guys, not arecord. >> 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. Sorry, yes you are right. >> > 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 I tried this one: arecord -c 1 -r 44100 -f S16 -M -D hw:0,0 -v arec.wav but it did not change anything. Still the files are much too small. Recording WAVE 'arec.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono Hardware PCM card 0 'SiS7019' device 0 subdevice 0 Its setup is: stream : CAPTURE access : MMAP_INTERLEAVED format : S16_LE subformat : STD channels : 1 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 22050 period_size : 5513 period_time : 125011 tick_time : 0 tstamp_mode : NONE period_step : 1 sleep_min : 0 avail_min : 5513 xfer_align : 5513 start_threshold : 1 stop_threshold : 22050 silence_threshold: 0 silence_size : 0 boundary : 1944986400 overrun!!! (at least 4.368 ms long) Status: state : XRUN trigger_time: 1277092780.321430383 tstamp : 1277092780.323362792 delay : 0 avail : 27562 avail_max : 27562 # grep avail arec-stdout2.log | sort | uniq -c 6 avail : 22053 13 avail : 22055 2 avail : 22058 1 avail : 22059 10 avail : 22060 4 avail : 22062 1 avail : 22063 2 avail : 22064 10975 avail : 27562 5 avail : 33075 2 avail : 38588 6 avail_max : 22053 13 avail_max : 22055 2 avail_max : 22058 1 avail_max : 22059 10 avail_max : 22060 4 avail_max : 22062 1 avail_max : 22063 2 avail_max : 22064 10975 avail_max : 27562 5 avail_max : 33075 2 avail_max : 38588 2 avail_min : 5513 So most often 'avail' is 27562 after an overrun when running arecord. I think it would be better to test with sox-rec but which options should be used? /hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |