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@schou.dk:
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