2 Apr
2014
2 Apr
'14
9:47 p.m.
I've started making tentative steps towards improving yoshimi - in particular
with respect to isolating MIDI, GUI and DSP.
The jack ring buffer is already used for data transfers from jack midi to the
dsp code, but I want to a) set up another buffer between jack midi and gui, and
b) if possible, try to do the same for alsa midi.
From what I've read, the jack ring buffer will happily work between any two
threads on a garbage-in-garbage-out basis.
However, around 2008 there was a lot of discussion about thread safety/memory
barriers etc. Was this ever resolved?
Also - and I don't know if this is actually a realistic situation - how would I
handle an all alsa setup? Would there be anything preventing me just linking to
the ring buffer itself?
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
2 Apr
2 Apr
9:56 p.m.
On Wed, Apr 02, 2014 at 08:47:12PM +0100, Will Godfrey wrote:
The jack ring buffer is already used for data
transfers
from jack midi to the dsp code
Why would you want to do that ? Jack MIDI is received by
Jack's realtime thread which also calls the DSP code (or
so I assume). So any MIDI events that will be handled
by the DSP code (normally note-on and off and controllers)
don't need to be buffered at all. You'd need to buffer
only those events that can't be handled by the real time
DSP code (e.g. program change).
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
11:17 p.m.
On Wed, 2 Apr 2014 19:56:54 +0000
Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Wed, Apr 02, 2014 at 08:47:12PM +0100, Will Godfrey
wrote:
I'm carefully feeling my way round the code trying to get familiar with it
before making any major changes. I don't know why it's done like that.
Unfortunately the person who implemented it is no longer here to ask.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
The jack ring buffer is already used for data
transfers
from jack midi to the dsp code
Why would you want to do that ? Jack MIDI is received by
Jack's realtime thread which also calls the DSP code (or
so I assume). So any MIDI events that will be handled
by the DSP code (normally note-on and off and controllers)
don't need to be buffered at all. You'd need to buffer
only those events that can't be handled by the real time
DSP code (e.g. program change).
Ciao,
10:13 p.m.
On 02.04.2014 21:47, Will Godfrey wrote:
I've started making tentative steps towards
improving yoshimi
I think this question must be asked:
Why would you want to do that? Just forget Yoshimi and work with the
original Zyn.
Are there any real advantages (however small!) that Yoshimi has and Zyn not?
And if these would be resolved in Zyn, would you still continue to
develop and use Yoshimi? (this is a trick question! Answering it yes
would make you a fanatic person by the definition that all logical
reaons point against a situation but a person still refuses to accept it)
Nils
11:31 p.m.
On Wed, 02 Apr 2014 22:12:55 +0200
Nils <list(a)nilsgey.de> wrote:
On 02.04.2014 21:47, Will Godfrey wrote:
I, and a number of other people, have found that yoshi is consistently more
stable, reliable and less prone to xruns under stress.
There are details in the way yoshi implements some features that some of us
prefer.
I frequently use very large patch sets. zyn is unable to load these even
if it saved them. I'm informed that this has been dealt with in one of the
development branches, but when that will appear in the release version is
unknown. For me, this is a show-stopper.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
I've started making tentative steps towards
improving yoshimi
I think this question must be asked:
Why would you want to do that? Just forget Yoshimi and work with the
original Zyn.
Are there any real advantages (however small!) that Yoshimi has and Zyn not?
And if these would be resolved in Zyn, would you still continue to
develop and use Yoshimi? (this is a trick question! Answering it yes
would make you a fanatic person by the definition that all logical
reaons point against a situation but a person still refuses to accept it)
Nils 
3 Apr
3 Apr
12:05 a.m.
On Wed, Apr 02, 2014 at 10:31:42PM +0100, Will Godfrey wrote:
I, and a number of other people, have found that yoshi
is consistently more
stable, reliable and less prone to xruns under stress.
...
I frequently use very large patch sets. zyn is unable to load these even
if it saved them. I'm informed that this has been dealt with in one of the
development branches, but when that will appear in the release version is
unknown. For me, this is a show-stopper.
In regards to this issue, I'm going to have to firmly sit with the approach that
I've been implementing in ZynAddSubFX for quite some time.
First, the overall issue is that both codebases have a lot of real time Faux pas.
The difference is how the projects have gone about trying to fix things.
In every case that I have observed in yoshimi where an xrun is less likely to
occur it is due to undefined behavior (almost exclusively through threading).
For the longest time the user interface has synchronized everything with a
horrid mutex, which was used in such a way that it really broke realtime
guarantees in quite a few dimensions, but when it was used it did ensure that
well defined program behavior was present.
I have seen a number of locations where yoshimi has simply omitted the use of
this with nothing else to stop nasal daemons from popping up.
This approach certainly can be seen as a shortcut to a better experience, but
it's not really a true fix.
I'm not encouraging the use of non-realtime operations at all, but in the mean
time I'll take a well defined error over undefined behavior.
As for a real fix, in what I've been calling the anti-broken system I've made
sure that this mutex is quite solidly dead and unsafe/costly operations do not
interfere with any audio generation.
This branch was quite time consuming to implement and the internals are working
quite well for the most part (and this conversion has also resulted in a number
of features that are getting fine tuned such as arbitrary midi learning, OSC
exposure of *all* parameters, basic undo, etc).
As per when this will appear in a release version, that will happen as soon as I
stop finding regressions in the user interface.
I cannot nail down any set timeline as I'm the only person actively working on
this part of the code and coding time varies wildly.
So, I'm fine with yoshimi continuing to plug along, but there seems to be some
FUD surrounding it's relationship to ZynAddSubFX.
This FUD goes back to some of the origins of the project when the code changes
were purported to drastically improve performance when 95% of that claim was
simply a basic change in compiler flags and those flags along with the 5% (and
then some) have all been integrated for those curious.
Does it appear to do some operations better than the current released version of
ZynAddSubFX?
Yes, loading a very large patch in the master version does end up blocking.
(In the ABS version this is simply a pointer swap)
Does it do so in a manner that is well defined and maintainable?
Not in my opinion
--Mark McCurry
5 Apr
5 Apr
7:14 p.m.
On Wed, 2014-04-02 at 22:31 +0100, Will Godfrey wrote:
I, and a number of other people, have found that yoshi
is consistently more
stable, reliable and less prone to xruns under stress.
I didn't experience that. I experienced that Yoshimi is only available
by packages nowadays and SynAddBla is droped, but also that Yoshimi's
default settings differ to SynAddSnip's default settings for the
packages and that by the default settings SynAddFoo's caused a better
sound quality. In the end they are both ok for the end user, I only care
about odd defaults.
10 Apr
10 Apr
8:10 p.m.
On Wed, 2014-04-02 at 20:47 +0100, Will Godfrey wrote:
[...]
Also - and I don't know if this is actually a
realistic situation - how would I
handle an all alsa setup? Would there be anything preventing me just linking to
the ring buffer itself?
It's just a ringbuffer, little thing. If you're concerned about a
dependency you can just copy the Jack one or choose from any number of
others floating around the web.
Here's my two, in C and C++ flavours, FWIW:
http://svn.drobilla.net/zix/trunk/zix/ring.h
http://svn.drobilla.net/zix/trunk/zix/ring.c
http://svn.drobilla.net/lad/trunk/raul/raul/RingBuffer.hpp
Last I checked, these, the Jack one, and the one(s) in Ardour are doing
the same things as far as barriers and correctness are concerned. I
can't rigorously claim they are correct, but they seem correctish and
several people have hammered on them with many threads with no
observable error.
There was a test suite / ringbuffer shootout (by Olivier Guilyardi and
subsequently tinkered with by others) called "rbtest", but the
repository seems to have fallen off the face of the Internet and I can't
find it anymore.
Cheers,
--
dr
9:15 p.m.
On Thu, 10 Apr 2014 14:10:23 -0400
David Robillard <d(a)drobilla.net> wrote:
On Wed, 2014-04-02 at 20:47 +0100, Will Godfrey
wrote:
[...]
Thanks a lot David. That was most helpful.
--
It wasn't me! (Well actually, it probably was)
... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
Also - and I don't know if this is actually a
realistic situation - how would I
handle an all alsa setup? Would there be anything preventing me just linking to
the ring buffer itself?
It's just a ringbuffer, little thing. If you're concerned about a
dependency you can just copy the Jack one or choose from any number of
others floating around the web.
Here's my two, in C and C++ flavours, FWIW:
http://svn.drobilla.net/zix/trunk/zix/ring.h
http://svn.drobilla.net/zix/trunk/zix/ring.c
http://svn.drobilla.net/lad/trunk/raul/raul/RingBuffer.hpp
Last I checked, these, the Jack one, and the one(s) in Ardour are doing
the same things as far as barriers and correctness are concerned. I
can't rigorously claim they are correct, but they seem correctish and
several people have hammered on them with many threads with no
observable error.
There was a test suite / ringbuffer shootout (by Olivier Guilyardi and
subsequently tinkered with by others) called "rbtest", but the
repository seems to have fallen off the face of the Internet and I can't
find it anymore.
Cheers,
3676
days inactive
3684
days old
linux-audio-dev@lists.linuxaudio.org
8 comments
7 participants
participants (7)
-
David Robillard -
Fons Adriaensen -
Mark D. McCurry -
Nils -
Ralf Mardorf -
Will Godfrey -
Will J Godfrey