[LAU] Regular Xruns?

Paul Davis paul at linuxaudiosystems.com
Sun Aug 9 07:36:26 EDT 2009

Ken - again, no picking on your personally, just want to clarify some
misconceptions for the record ...

On Fri, Aug 7, 2009 at 10:16 PM, Ken Restivo<ken at restivo.org> wrote:
> That makes sense to me. The question I have now is: who or what is doing the resampling? Is it the card, internally? Or ALSA? If it's ALSA doing the resampling, then the problem is likely the driver for the card.

no ALSA driver that i am aware of does resampling. however, libasound,
the ALSA library used by all ALSA applications (including JACK when
run with the ALSA backend) can resample if you use a device name that
permits it. the most common device name for this is something like
"plughw:N", which will do resampling if the underlying hardware does
not support the sample rate you ask for. it is not particularly high
quality resampling. if you use the "hw:N" device name, as is
recommended for JACK, no resampling will ever occur in software.

> Wherever it is, either ALSA driver or the card's firmware or hardware, it may be a 32-bit or 16-bit overflow. When audio cards are running in normal mode, they just sit there most  of the time unless you give them audio. But with JACK running, the card is constantly being fed something (zeroes? I haven't looked to find out what exactly) all the time. You'll notice your interrupt counter going up and up when JACK is running, even if no sound is coming out, for instance.

whenever you start an audio interface, it is running until you stop
it. perhaps you mean that other programs don't keep the interface open
when they are not playing audio. that would vary on a case by case
basis. ALSA also permits the app to leave the card running without the
app feeding anymore data - the app tells ALSA how to handle the
requirement to refill the card's data buffer - but i doubt if many
apps use this part of the ALSA API. in addition,

> So my guess is that, every 14 minutes, enough frames are pumped to the card  for that int/long/whatever to overflow. The strange sounds might be as it gets close to that overflow point.

nothing is going to overflow for hours. and when it does, nothing
happens. you're just going to have trust this hand-waving assertion,
and i'm willing to be proven wrong in the case of a particular
driver/hw combination.


More information about the Linux-audio-user mailing list