On Wed, 30 Sep 2009, Nedko Arnaudov wrote: >>>> I get "wrong" sound. JACK reports no xruns. >>>> >>>> http://nedko.arnaudov.name/tmp/phasex.wav >> >> Yup. I know the sound well, and hopefully now it's nothing more than >> a memory. The broken ringbuffer read has been fixed, and now uses two >> buffer periods instead of one. 0.12.0-pre1 should treat you right. >> > > I fixed it by tweaking the thread priorities in phasex settings window. > > midi_thread_priority = 70; > engine_thread_priority = 75; > > Are you sure that it was caused by a ringbuffer problem? The ringbuffer problem was the sure culprit of the bad sound generated on my machine. The old code blindly assumed that JACK would want to read the entire buffer period at once. If nframes in the process callback changes between calls, it was possible to read off the end of the ringbuffer. Usually this would happen during a CPU crunch. >> It's been suggested in the past to put the softirq-high threads at a >> high priority (just under the rtc, like you have done), but I get >> xruns whenever I put it above JACK. What kind of audio hardware and >> clock hardware do you have? Just curious. > > soundcard is emu10k1 (sblive value) > no idea about clock hardware Do you get the same or better realtime performance by setting the softirq-high thread to SCHED_OTHER? >> Give 0.12.0-pre1 a spin and let me know how it goes. > > If there is JACK MIDI, there will be one thread less, right? That's the plan ;-} > -- > Nedko Arnaudov <GnuPG KeyID: DE1716B0> > Thanks Nedko. You prompted me to make some serious fixes to both the phasex codee and to my -rt laptop! Cheers, --ww _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
