[linux-audio-user] Commercial "clone" of ZynAddSubFX?

[Folderol]

On Sat, 03 Feb 2007 16:42:50 +0100
Lars Luthman <lars.luthman at gmail.com> wrote:

> On Sat, 2007-02-03 at 15:25 +0000, Folderol wrote:

> > Why is there any lock capability from the GUI? Surely, as this is not in
> > any way time critical, it should be able to operate in the 'spaces'
> > left by the audio & MIDI?
> 
> The locks don't really have anything to do with timing, they are used to
> protect data structures. The GUI thread may e.g. create a new instance
> of an insertion effect, which needs to be inserted into the main engine
> for the audio thread to use it. Since all sorts of havoc could ensue if
> the audio thread tried to access a partially created effect instance,
> the GUI thread locks the mutex while creating the effect and modifying
> the data structures.

Ah! I was rather assuming some kind of double buffering would be used
rather like we used to use for the BBC B Model B screens - yes *that*
long ago :) 

> > Also (and I speak from the depths of ignorance here) I can't see any
> > circumstance for MIDI wanting to lock out audio. If there are MIDI
> > signals wanting to change the data then surely it would make sense to
> > wait in some form of queue, dipping in quickly between buffer fills.
> 
> The MIDI thread creates new notes and changes parameters in response to
> MIDI events that the audio thread will need to know about in order to
> render said notes with said parameters. To avoid the same problem as the
> GUI (audio thread accessing partially updated data structures), it locks
> the mutex while doing these changes.
> 
> There are ways to do this without blocking the audio thread, but it
> requires a bit of clever programming and if you don't think about it
> from the start it can require a more or less complete redesign to fix
> it.
> 
> 
> --ll

If buffering is the problem, would it not be possible (say) to indirect
whatever pointers there are to the data so that the routine which
wishes to make changes grabs a new chunk of memory, swapping the
pointers once it has completed the change.

If the reading routine only grabs the indirected pointers at the start
of its buffer then it won't notice the change until it has to go back
to the beginning of the data. If it sees that the pointers have
changed it can presumably hand off the old data to whatever garbage
routine is in place, then carry on with the new pointers.

-- 
Will J G