23 Apr
2005
23 Apr
'05
8:18 a.m.
Dave Robillard wrote:
I would never block in process(). I guess I'd try to detect if there's a
xrun, and play silence if that's the case.
I want to vary
the pitch in realtime, and even to totally enable/disable
the pitch-shifting routines when needed, always in realtime, while rolling.
I'm not sure if all that's still linear. The CPU load of my process()
callback may remain constant when the user vary the pitch, but it will
suddenly increase/decrease if the user enables/disables pitch-shifting.
Is this still deterministic/linear ? If not, is spanning a new thread
the only alternative ?
Yes, this is fine to do.
Having another thread doing this, and having the RT audio thread read
from it through a ringbuffer won't help - if the slave thread is too
slow, everything will go to hell anyway. There's a million reasons why
doing your audio work in another thread is an awful idea (the most
obvious being you need to /block/ the Jack thread waiting for it, which
is a no-no).
Ever used one of those programs that had Jack support
grafted on after
the fact, that zombie every five minutes? That's precisely because they
do this, instead of processing audio in the callback thread in a
"pull-based" manner.
Ok, so doing the real job in process() is usually the right way, as long
as you don't perform syscalls. I was confused about this, and wondering
if the process() callback wasn't just a place where to memcpy(), with
worker threads doing the real work aside. I guess this is still true, if
you need to malloc(), free(), etc..
Anyway, doing the DSP in process() makes it much easier for me as well.
I'll go that way.
Thanks
--
og