On Fri, 24 Jan 2003, Kai Vehmanen wrote:
On Fri, 24 Jan 2003, Kjetil S. Matheussen wrote:
This
means that you could be having small xruns all the time! Of course,
really long breaks are always audible, but shorter ones are sometimes
quite subtle. Still, you are losing audio data.
I guess so. But its not
necesarrily very import, at least not for (most
kinds of) live performance. Is there a quick way to patch pd so that it
detects xruns?
Yup, replace the set_stop_mode call with:
snd_pcm_sw_params_set_stop_threshold(handle, sw_params, XXX);
... where XXX is the buffersize (ie. 64*27=1728).
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
ecasound+jackd+freqtweak+qjackconnect as a normal user, with the same
1.5->39ms latency as with pd, and while there are occasional audible
artifacts, it does indeed work!
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? :)
--