linux-kernel - Re: PROBLEM: SIS7019 stops recording after 42 min

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 22 Jun 2010 23:00:47 -0400
From:	David Dillow <dave@...dillows.org>
To:	linux@...ou.dk
Cc:	linux-kernel@...r.kernel.org, alsa-devel@...a-project.org
Subject: Re: PROBLEM: SIS7019 stops recording after 42 min

On Mon, 2010-06-21 at 22:10 +0200, Hans Schou wrote:
> 2010/6/21 Hans Schou <linux@...ou.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.

If I use:

strace -tt -T -o record.log arecord -f S16 -r 44100 -c 1 -d 3600 \
	--buffer-size=32768 --period-size=16384 -v -t raw - > /dev/null

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.

Then, using:

strace -tt -T -o record.log arecord -f S16 -r 44100 -c 1 -d 3600 \
	--buffer-size=32768 --period-size=8192 -v -t raw - > /dev/null

I was able to push it into the 10-second pause failure mode, without
hitting any overruns. Initially it has a similar alternating pattern of
0.6ms then 363ms capture times until it drops into a 10 second pause
just after 42 minutes.

Now that I finally got my hardware going and can reproduce this, I'll
dig into it over the next few evenings.

Thanks for the report and help narrowing down the focus area,
Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/