On Fri, 2005-22-04 at 20:10 +0200, Olivier Guilyardi wrote:
> Erik de Castro Lopo wrote:
>
> >On Fri, 22 Apr 2005 16:48:32 +0100
> >Steve Harris <S.W.Harris@email-addr-hidden> wrote:
> >
> >
> >
> >>Doing heavy jobs in the process() callback is fine, as long as the CPU
> >>load is deterministic. I this case I think it should be.
> >>
> >>
> >
> >Yep, the CPU load of the sample rate conversion process of libsamplerate
> >is pretty close to linearly related to the size of the blocks you are
> >converting.
> >
> >
> 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.
Blocking IO is satan, avoid at all costs.
-DR-
Received on Sat Apr 23 12:15:09 2005
This archive was generated by hypermail 2.1.8 : Sat Apr 23 2005 - 12:15:11 EEST