PROBLEM: SIS7019 stops recording after 42 min
in [Kernel]
|
Prev: ~~Hi~~
Next: MMC: Add JZ4740 mmc driver
From: David Dillow on 21 Jun 2010 10:10 On Mon, 2010-06-21 at 07:56 +0200, Hans Schou wrote: > 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). > Only 35 minutes of recording but I was running in 50min. Ok, cool, we see the problem with arecord as well, though you were getting overrun messages as well? > > 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? Sorry, that should be CONFIG_SND_PCM_XRUN_DEBUG in the kernel configuration, but if we can demonstrate this with arecord, there's no real reason to recompile your kernel at this point. > > 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. An overrun means that arecord didn't run for 500ms, and the load average won't really tell you much about that -- latency can happen with low loads. That said, I'm suspecting that you've found a problem in the driver, and I'd lay odds it is in the handling of multiple periods per buffer. > >> > 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. Ok, read/write vs mmap is not a differentiating factor, good deal. > 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? I don't know the options available on sox, but if you can use arecord to reproduce, then that is probably the best tool for the job. Can you set it up to use two periods per buffer and see if you still can reproduce? Options would look like -B 250000 -F 125000. A second test with -B 1000000 -F 500000 would be interesting, if the hw can handle buffers of that size -- I don't recall offhand. I will hopefully have my hardware back up and running tonight; BTW, what distro are you using? I'm trying Fedora 13, but I'm expecting to run into trouble with the lack of cmov support on the processor. Thanks, 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 13:50 2010/6/21 David Dillow <dave(a)thedillows.org>: >> Only 35 minutes of recording but I was running in 50min. > > Ok, cool, we see the problem with arecord as well, though you were > getting overrun messages as well? Yes, a lot of overrun. At least one per second. >> How do I enable SND_PCM_XRUN_DEBUG with sox? > > Sorry, that should be CONFIG_SND_PCM_XRUN_DEBUG in the kernel > configuration, but if we can demonstrate this with arecord, there's no > real reason to recompile your kernel at this point. OK, I'll skip that. It takes rather long time to compile. >> Right now uptime says >> � �load average: 0.19, 0.21, 0.18 >> but strace and top is the bad guys, not arecord. > > An overrun means that arecord didn't run for 500ms, and the load average > won't really tell you much about that -- latency can happen with low Well, I did not see that with sox. It was running fine for 42 min. > loads. That said, I'm suspecting that you've found a problem in the > driver, and I'd lay odds it is in the handling of multiple periods per > buffer. > I don't know the options available on sox, but if you can use arecord to > reproduce, then that is probably the best tool for the job. Can you set > it up to use two periods per buffer and see if you still can reproduce? > Options would look like -B 250000 -F 125000. A second test with -B > 1000000 -F 500000 would be interesting, if the hw can handle buffers of > that size -- I don't recall offhand. I have just started it with -B 250000 -F 125000 and get a lot of overrun. I skipped using strace to make less stress. cmdline is now: arecord -B 250000 -F 125000 -c 1 -r 44100 -f S16 -M -D hw:0,0 -v arec.wav overrun!!! (at least 0.201 ms long) Status: state : XRUN trigger_time: 1277140527.1826705 tstamp : 1277140527.2005279 delay : 0 avail : 16537 avail_max : 16537 overrun!!! (at least 0.207 ms long) Status: state : XRUN trigger_time: 1277140527.128608572 tstamp : 1277140527.128793445 delay : 0 avail : 16537 avail_max : 16537 overrun!!! (at least 0.167 ms long) Status: state : XRUN trigger_time: 1277140527.256925501 tstamp : 1277140527.257071819 delay : 0 avail : 16537 avail_max : 16537 > I will hopefully have my hardware back up and running tonight; BTW, what > distro are you using? I'm trying Fedora 13, but I'm expecting to run > into trouble with the lack of cmov support on the processor. Debian stable. /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 21 Jun 2010 15:00 On Mon, 2010-06-21 at 19:42 +0200, Hans Schou wrote: > 2010/6/21 David Dillow <dave(a)thedillows.org>: > > I don't know the options available on sox, but if you can use arecord to > > reproduce, then that is probably the best tool for the job. Can you set > > it up to use two periods per buffer and see if you still can reproduce? > > Options would look like -B 250000 -F 125000. A second test with -B > > 1000000 -F 500000 would be interesting, if the hw can handle buffers of > > that size -- I don't recall offhand. > > I have just started it with -B 250000 -F 125000 and get a lot of overrun. > I skipped using strace to make less stress. > > cmdline is now: > arecord -B 250000 -F 125000 -c 1 -r 44100 -f S16 -M -D hw:0,0 -v arec.wav > > overrun!!! (at least 0.201 ms long) > Status: > state : XRUN > trigger_time: 1277140527.1826705 > tstamp : 1277140527.2005279 > delay : 0 > avail : 16537 > avail_max : 16537 This really makes me think the system just cannot keep up. Can you post the initial output to verify that it is getting two periods per buffer, please? If you are getting overruns and small files in that configuration, there is not much I think I do to help -- that uses the hardware's built-in support for generating the appropriate interrupts. Also, does it do the same without the -M ? And you may wish to try longer and shorter periods to see if you get so many overruns. Also, what storage are you using? Does it support DMA? PIO modes can be very slow... > > I will hopefully have my hardware back up and running tonight; BTW, what > > distro are you using? I'm trying Fedora 13, but I'm expecting to run > > into trouble with the lack of cmov support on the processor. > > Debian stable. Thanks, I'll fall back to that if getting Fedora going looks to be more trouble than it is worth. 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 15:00 2010/6/21 Hans Schou <linux(a)schou.dk>: > 2010/6/21 David Dillow <dave(a)thedillows.org>: > >>> Only 35 minutes of recording but I was running in 50min. >> >> Ok, cool, we see the problem with arecord as well, though you were >> getting overrun messages as well? > > Yes, a lot of overrun. At least one per second. > >>> How do I enable SND_PCM_XRUN_DEBUG with sox? >> >> Sorry, that should be CONFIG_SND_PCM_XRUN_DEBUG in the kernel >> configuration, but if we can demonstrate this with arecord, there's no >> real reason to recompile your kernel at this point. > > OK, I'll skip that. It takes rather long time to compile. > >>> Right now uptime says >>> � �load average: 0.19, 0.21, 0.18 >>> but strace and top is the bad guys, not arecord. >> >> An overrun means that arecord didn't run for 500ms, and the load average >> won't really tell you much about that -- latency can happen with low > > Well, I did not see that with sox. It was running fine for 42 min. > >> loads. That said, I'm suspecting that you've found a problem in the >> driver, and I'd lay odds it is in the handling of multiple periods per >> buffer. > >> I don't know the options available on sox, but if you can use arecord to >> reproduce, then that is probably the best tool for the job. Can you set >> it up to use two periods per buffer and see if you still can reproduce? >> Options would look like -B 250000 -F 125000. A second test with -B >> 1000000 -F 500000 would be interesting, if the hw can handle buffers of >> that size -- I don't recall offhand. > > I have just started it with �-B 250000 -F 125000 and get a lot of overrun. > I skipped using strace to make less stress. > > cmdline is now: > arecord -B 250000 -F 125000 -c 1 -r 44100 -f S16 -M -D hw:0,0 -v arec.wav This gave a 191069598 bytes long file. What does this test actually show regarding the original problem with stopping after 42 min? I have just started: arecord -B 1000000 -F 500000 -c 1 -r 44100 -f S16 -M -D hw:0,0 -v arec.wav and I only got one overrun. What I did was that logged in on another ssh console and executed "ls". Here is a complete screen dump after running 2 minutes: + arecord -B 1000000 -F 500000 -c 1 -r 44100 -f S16 -M -D hw:0,0 -v arec.wav 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 : 32768 period_size : 22050 period_time : 500000 tick_time : 0 tstamp_mode : NONE period_step : 1 sleep_min : 0 avail_min : 22050 xfer_align : 22050 start_threshold : 1 stop_threshold : 32768 silence_threshold: 0 silence_size : 0 boundary : 1445068800 overrun!!! (at least 826.140 ms long) Status: state : XRUN trigger_time: 1277144902.603264297 tstamp : 1277144903.428975238 delay : 0 avail : 44108 avail_max : 44108 overrun!!! (at least 0.077 ms long) Status: state : XRUN trigger_time: 1277144938.378978657 tstamp : 1277144938.379038604 delay : 0 avail : 42344 avail_max : 42344 /hans /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 21 Jun 2010 15:10
2010/6/21 David Dillow <dave(a)thedillows.org>: > On Mon, 2010-06-21 at 19:42 +0200, Hans Schou wrote: >> cmdline is now: >> arecord -B 250000 -F 125000 -c 1 -r 44100 -f S16 -M -D hw:0,0 -v arec.wav > This really makes me think the system just cannot keep up. Can you post > the initial output to verify that it is getting two periods per buffer, > please? Then I have to run it again. I do not have it on the screen anymore. I will do that after the test I'm running now - as mentioned before. I have turned on my signal generator with 400Hz. I will give it a try with listen to it, to hear any clicks when the overrun occur. > Also, does it do the same without the -M ? And you may wish to try > longer and shorter periods to see if you get so many overruns. > Also, what storage are you using? Does it support DMA? PIO modes can be > very slow... On a daily basis I use USB flash memory stick and have done this more than a year but always less than 42 min. Right now I'm using old 4GB external hard disk connected through USB. /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/ |