9 Aug
2009
9 Aug
'09
9:57 a.m.
On Sunday 09 August 2009 14:36:26 Paul Davis wrote:
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)?
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(a)restivo.org> wrote:
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?
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.