24 Jan
2003
24 Jan
'03
8:44 p.m.
On Fri, 24 Jan 2003, Kjetil S. Matheussen wrote:
Hmm, what's the exact error you get? One thing that will cause you trouble
is that audio playback will stop after the first xrun. You have to restart
the stream (stop-prepare-start) to recover from an xrun. This is also the
source of the longer audible breaks that occur with current JACK's ALSA
driver when xruns occur.
True, I just posted a patch that does this to jackit-devel. So, so, as I
said, competition is a good thing! ;D So thanks for releasing k_jack
and helping with the debugging/tracing work.
Yup, replace
the set_stop_mode call with:
snd_pcm_sw_params_set_stop_threshold(handle, sw_params, XXX);
I'm not able to
make that work. Just gets a message about stock audio,
no matter how big buffer it is. But thats not important. The difference
is definitely notable. I've just patched jackd to ignore
all xruns the way pd does, and yup, I can do all kinds of stuff as a
normal user (with ./jackd -p 64 -n 27). I'm currently running
Thats very nice.
How about an option for jack to ignore xruns then? And, are you absolutely sure its not a bug in alsa,
reporting to many
xruns? :)
This is very unlikely. The code in alsa-kernel/driver that handles this
logic is _very_ robust. I haven't done much driver work, but I've still
gone through those functions at least a hundred times, and I bet many
other developers have done the same. The common PCM subsystem used by all
ALSA low-level drivers is really high-quality code. The fact that all
drivers can benefit from this common code library is IMHO one of the
biggest benefits ALSA brings!
--
http://www.eca.cx
Audio software for Linux!