8 Aug
2009
8 Aug
'09
12:16 a.m.
On Fri, Aug 07, 2009 at 02:57:56PM +0200, Arnold Krille wrote:
Hi,
On Friday 07 August 2009 14:54:30 James Stone 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.
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.
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.
Total wild guess here, but that's where I'd think of looking.
-ken
In the end, I tracked down my 14 minute xruns to
running the SBLive at
44100 instead of 48000.. I wonder if that would help with the OP problem?
Now, is this a bug with jack (v 0.116) or just a design problem with the
SBLive? I know the SBLive runs at 48000, and has to be resampled (or
something similar that I don't understand) to run at 44100, but surely
that shouldn't cause xruns.. The slow build of static before the xrun
now makes much more sense to me!
I think this could be the problem also for the OP! Nowadays many sound devices
just work with fixed 48000kHz and resample when opened with other rates...