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:	Sun, 20 Jun 2010 10:26:10 -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

Please keep me on the cc list, I'll see your message sooner in my Inbox
than my mailing list folders.

On Sun, 2010-06-20 at 08:20 +0200, Hans Schou wrote:
> > On Sat, 2010-06-19 at 16:13 +0200, Hans Schou wrote:
> >> Hi
> >>
> >> I have a problem with recording sound when using the sound chip
> >> SIS7019 with both kernel 2.6.26 and 2.6.34. After recording about 42
> >> minutes it kind a stops recording, more precisely it is taking a pause
> >> of exactly 10 seconds between each reading.
> >>
> >> As recorder I have tried several programs and all of them fails after
> >> 42 minutes. Some programs uses Alsa and some uses the old deprecated
> >> method. In this example I have logged sox rec.
> >>
> >> Recording method in a script:
> >>   strace -tt -o strace.log rec -c 1 -r 44100 -2 sox.wav &
> >>   sleep 3000
> >>   kill $?
> >
> > I think the answer is no, but to be sure -- are you talking directly to
> > the hardware device, or are you going through pulseaudio?
> 
> Eh? No to what? Alsa?

Pulseaudio.

>  I am not really sure. In strace I can see 'rec'
> uses ioclt which could implies that it is talking directly to
> hardware.

Probably, but I'm not familiar enough with the library/user-space side
of alsa to know how it talks to plugins. I expect you are correct,
though.

> > While rec is running, can you capture the configuration using
> > head -1000 /proc/asound/card0/pcm0c/sub0/*
> 
> Below was captured while running:
>    arecord -c 1 -r 44100 -f S16 arec01.wav

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.

> I got a strange error message from arecord while recording at rate 44100:
> overrun!!! (at least 0.188 ms long)
> overrun!!! (at least 0.190 ms long)
> overrun!!! (at least 0.191 ms long)
> 
> Could this be a clue?

Perhaps; 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.

Getting overruns on SiS 550 based devices isn't entirely surprising, as
it doesn't have a huge amount of horsepower or memory. If you have too
much going on in the background, it is very easy to not have enough time
to processes all of the captured data, especially if you are running
short period/buffer sizes.

> The error does occur with rate 8000 8bit (the default).

Do you mean 'does not occur'? That may be more expected -- 8khz/8bit has
approximately 9% of the data as 44.1khz/16bit.

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

Yes, for testing if the mmap interface is the problem. You can also use
-v to have it print more information, including the source of the data
(hw vs Pulseaudio). To check 1 period vs 2, you can use the
--period-size/--buffer-size options. I seem to recall that there is a
bug lurking around there somewhere, so you should check that you got 1
period using -v or the proc files. You may have to fallback to the -F/-B
options and convert samples to microseconds.

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/