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:
Pulseaudio.
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.
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.
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.
Do you mean 'does not occur'? That may be more expected -- 8khz/8bit has
approximately 9% of the data as 44.1khz/16bit.
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
--
