Date:	Mon, 21 Jun 2010 10:06:20 -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 07:56 +0200, Hans Schou wrote:
> 2010/6/20 David Dillow <dave@...dillows.org>:
> 
> > 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.
> 
> Over night I have been running arecord several times. Alle wav-files
> are much below the expected size 264600000 bytes (44100*2*60s*50min).

> Only 35 minutes of recording but I was running in 50min.

Ok, cool, we see the problem with arecord as well, though you were
getting overrun messages as well?

> > 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.
> 
> How do I enable SND_PCM_XRUN_DEBUG with sox?

Sorry, that should be CONFIG_SND_PCM_XRUN_DEBUG in the kernel
configuration, but if we can demonstrate this with arecord, there's no
real reason to recompile your kernel at this point.

> > Getting overruns on SiS 550 based devices isn't entirely surprising, as
> > it doesn't have a huge amount of horsepower or memory.
> 
> Well, I usually don't have problem with that. I have samba running but
> I don't access the recorded files while recording, so it is not a
> problem.
> 
> Right now uptime says
>    load average: 0.19, 0.21, 0.18
> but strace and top is the bad guys, not arecord.

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
loads. That said, I'm suspecting that you've found a problem in the
driver, and I'd lay odds it is in the handling of multiple periods per
buffer.

> >> > 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
> 
> I tried this one:
>   arecord -c 1 -r 44100 -f S16 -M -D hw:0,0 -v arec.wav
> but it did not change anything. Still the files are much too small.

Ok, read/write vs mmap is not a differentiating factor, good deal.

> So most often 'avail' is 27562 after an overrun when  running arecord.
> 
> I think it would be better to test with sox-rec but which options
> should be used?

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 will hopefully have my hardware back up and running tonight; BTW, what
distro are you using? I'm trying Fedora 13, but I'm expecting to run
into trouble with the lack of cmov support on the processor.

Thanks,
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/

Powered by blists - more mailing lists