[LAU] Regular Xruns?

[David Baron]

On Sunday 09 August 2009 14:36:26 Paul Davis wrote:
> 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.
If I am playing a 44100 file through xmms->jack (set to 48000) to default hw 
out (hw:0 ?)--it sounds 100% OK so something is doing the resampling. The old 
xmms?

>
> > 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.
Since the switch to 48000 does get rid of the regular periodic Xruns (others 
may still occurs--not a rt-patched kernel), if this hypothesis not 
appropriate, what was causing the Xruns (which the fact of their occurance was 
not particularly hardware or kernel dependent though the period may have 
been)?