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:	Mon, 21 Jun 2010 15:06:57 -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 20:49 +0200, Hans Schou wrote:
> 2010/6/21 Hans Schou <linux@...ou.dk>:
> > 2010/6/21 David Dillow <dave@...dillows.org>:
> >> 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.

My thought is that you may have been somewhat fortunate and did not see
an overrun for 42 minutes. I am trying to narrow down if this is an
issue with sox's overrun handling, if there is a big with handing
anything other than two periods per buffer, or some other generic bug in
the driver.

> >> 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'm trying to have you reproduce the original problem using 2 periods
per buffer so that I can localize the likely location of a driver bug.
If it only happens when there is not 2 periods per buffer, then that
points to one set of timing code. If it also happens with 2 periods per
buffer, then that points to a more generic bug.

> 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".

That sounds like a scheduling latency issue, yes.

> 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:

>   buffer_size  : 32768
>   period_size  : 22050

Ok, please play with the options until you can get buffer_size = 2 *
period_size. That will eliminate the alternate timing code from the
path. I expected that options you gave to do that, but apparently there
is something else keeping that from happening.

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/