On Tue, 2010-06-22 at 23:00 -0400, David Dillow wrote: > On Mon, 2010-06-21 at 22:10 +0200, Hans Schou wrote: > > 2010/6/21 Hans Schou <linux@xxxxxxxx>: > > > > > 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. The driver's funkiness may be limited to the more than 2 periods per buffer/10 second pause issue. > 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. I can reproduce the alternating pattern of periods using a different device, so this may be something in the core code of ALSA. Hardware PCM card 0 'HDA Intel' device 0 subdevice 0 Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 32768 period_size : 16384 period_time : 371519 tstamp_mode : NONE period_step : 1 avail_min : 16384 period_event : 0 start_threshold : 1 stop_threshold : 32768 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 0 hw_ptr : 0 strace -T gives: ioctl(4, 0x80184151, 0x7fff532cff70) = 0 <0.371672> write(1, ..., 65536) = 65536 <0.000035> ioctl(4, 0x80184151, 0x7fff532cff70) = 0 <0.742746> write(1, ..., 65536) = 65536 <0.000013> ioctl(4, 0x80184151, 0x7fff532cff70) = 0 <0.000027> write(1, ..., 65536) = 65536 <0.000016> ioctl(4, 0x80184151, 0x7fff532cff70) = 0 <0.742694> write(1, ..., 65536) = 65536 <0.000011> ioctl(4, 0x80184151, 0x7fff532cff70) = 0 <0.000038> write(1, ..., 65536) = 65536 <0.000024> ioctl(4, 0x80184151, 0x7fff532cff70) = 0 <0.742600> The first period gets clocked out close to the expected time -- 371.672ms actual vs 371.519 ms expected -- but then we're either running almost a full buffer -- 742.746ms actual vs 743.038ms buffer -- or very, very short at 0.027ms. Since this problem is not related to the SiS7019 driver, I'll leave it to later -- or for others to investigate. Using three periods per buffer sees a similar pattern, but one has an extra period time to work within. Dave _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
