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? :) --
