Subject: Re: [linux-audio-dev] how vst handles parameter updates
From: Abramo Bagnara (abramo_AT_alsa-project.org)
Date: Fri Dec 07 2001 - 20:33:25 EET
Paul Davis wrote:
>
> Direct from the man himself (karl steinberg):
>
> ----------------------------------------------------------------------
> >1) does VST envision that the actions of setParameter and/or
> > setParameterAutomated are carried out synchronously or asynchronously
> > with respect to process()/processReplacing()? should a plugin expect
> > that a given parameter remain at a constant value throughout the
> > duration of a call to process(), or that it could change at any time?
>
> the latter is true. the current model allows to pre-empt on either side
> (parameter changes may happen during the audio process, and vice versa).
> timestamped parameters are another solution which we'd like to promote for
> the next iteration of this API.
>
> you may consider to latch 'fragile' parameters for now (means to stuff them
> into local variables and use only those within the sample-loop).
>
> >2) how do VST plugin+editor combinations handle moving non-scalar data
> > into the plugin in an atomic fashion? if i write a parametric EQ
> > whose editor features a shapeable curve, and i represent the curve
> > with 200 data points, how do i set the values of these points in a
> > way that is guaranteed not to interfere with
> > process()/processReplacing() ?
> >
>
> you have to solve that yourself. there was recently a very interesting
> thread here about 'lock-less' multithreaded data access.
>
> you might use a class or structure or array and access it
> via a pointer (or a 'double-pointer'). changing the pointer can be assumed
> to be atomic, you can even sync the pointer change at the beginning of
> either process. semaphores and mutexes are tricky, as they (may) block the
> audio thread.
The pointer (or 'double-pointer') solution is definitely bogus.
I guess this imply that the reader switch to new area, but the reader
cannot know if the new area is ready. And too if the writer zero the
pointer (or use another way) before to access it, we still have the
atomicity problem.
If you read the way I wrote for pcm_meter in ALSA I think you'll find a
nice solution without any apparent drawback.
Neither write nor read side blocks.
It's a "read, check, use or discard" approach.
-- Abramo Bagnara mailto:abramo_AT_alsa-project.orgOpera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org It sounds good!
This archive was generated by hypermail 2b28 : Fri Dec 07 2001 - 20:29:31 EET