30 Sep
2009
30 Sep
'09
9:42 a.m.
On Wed, 30 Sep 2009, Nedko Arnaudov wrote:
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.
Do you get the same or better realtime performance by setting the
softirq-high thread to SCHED_OTHER?
That's the plan ;-}
> 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.
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 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? --
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