Re: [linux-audio-dev] jack_process and pitch-shifting

Dave Robillard wrote:

>>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).
>
>
>
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.

>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