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

From: Lars Luthman <lars.luthman@email-addr-hidden>
Date: Sat Feb 03 2007 - 17:42:50 EET

On Sat, 2007-02-03 at 15:25 +0000, Folderol wrote:
> On Sat, 03 Feb 2007 15:49:25 +0100
> Lars Luthman <lars.luthman@email-addr-hidden> 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@email-addr-hidden> 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

Received on Sat Feb 3 20:15:03 2007

This archive was generated by hypermail 2.1.8 : Sat Feb 03 2007 - 20:15:03 EET