3 Feb
2007
3 Feb
'07
12:10 p.m.
On Sat, 03 Feb 2007 16:42:50 +0100
Lars Luthman <lars.luthman(a)gmail.com> wrote:
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 :)
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
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. 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