On Sat, 2007-02-03 at 15:25 +0000, Folderol wrote: > On Sat, 03 Feb 2007 15:49:25 +0100 > Lars Luthman <lars.luthman@xxxxxxxxx> wrote: > > > On Sat, 2007-02-03 at 14:39 +0000, Folderol wrote: > > > On Sat, 3 Feb 2007 01:01:18 -0500 (EST) > > > Larry Troxler <lt@xxxxxxxxxxx> wrote: > > > > > > > On Fri, 2 Feb 2007, Ken Restivo wrote: > > > > > Wish there were a way to approach all the talented hackers who are > > > > > unfortunately wasting their time working on trying to crack it, > > > > > and instead get them a copy of the Zyn source, to revamp it from > > > > > scratch and make it RT-safe. > > > > > > > > Zyn isn't RT safe? Could you elaborate or point to a link? I remember > > > > reading something about this, and was hoping to use it for live > > > > performance. > > > > > > I have heard several comments to this effect, and also that the code > > > in Zyn is 'a nightmare' however I have not heard anything specific that > > > one can really get a handle on. > > > > I wouldn't say that it's a "nightmare", but it's not designed with > > RT-safety in mind. For example, there is a big mutex protecting some of > > the data structures that is locked from the audio thread, from the MIDI > > thread (in the case of ALSA MIDI) and from the GUI thread, which will > > cause audio glitches if the mutex is busy when the audio thread tries to > > lock it. And some other things. The actual synth algorithms are great, > > and it would be very nice if someone could clean it up a bit and make it > > a proper JACK client (or plugin, or whatever - as long as it's RT-safe). > > Ok I can understand that... to some degree. > > 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
Attachment:
signature.asc
Description: This is a digitally signed message part
