1 Aug
2009
1 Aug
'09
2:38 a.m.
ZynAddSubFX is a truly amazing piece of work, an amazing little synth.
Sadly, when it comes to jack operation it's a case of flawed genius.
There's an experimental patch against the 2.4.0 release tarball at
<http://www.graggrag.com/?q=node/19>.
I've restructured the audio and midi drivers, and added Alsa audio. It
builds with multiple audio/midi options, nominate what to actually use
via command line parameters. The build options and default choices are
set as per normal in Makefile.inc.
If any mildly adventurous zyn enthusiast cared to try a build && run, I'd
appreciate 25 words or less on the experience. At the moment I'm mostly
interested in jack audio/midi performance.
The patch applies from the ZynAddSubFX-2.4.0/ directory, then off to src/
to edit Makefile.inc and build as usual.
cheers, Cal
1 Aug
1 Aug
5:45 a.m.
I would be happy to do this. Could you tell a bit more about the jack design
in Zyn, what is bad and what you have fixed.
If I know what to expect as a difference it is easier to make comparative
tests.
/Lars
2009/8/1 cal <cal(a)graggrag.com>
ZynAddSubFX is a truly amazing piece of work, an
amazing little synth.
Sadly, when it comes to jack operation it's a case of flawed genius.
There's an experimental patch against the 2.4.0 release tarball at
<http://www.graggrag.com/?q=node/19>.
I've restructured the audio and midi drivers, and added Alsa audio. It
builds with multiple audio/midi options, nominate what to actually use
via command line parameters. The build options and default choices are
set as per normal in Makefile.inc.
If any mildly adventurous zyn enthusiast cared to try a build && run, I'd
appreciate 25 words or less on the experience. At the moment I'm mostly
interested in jack audio/midi performance.
The patch applies from the ZynAddSubFX-2.4.0/ directory, then off to src/
to edit Makefile.inc and build as usual.
cheers, Cal
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
7:04 a.m.
Lars-Erik Helander wrote:
I would be happy to do this. Could you tell a bit more
about the jack
design in Zyn, what is bad and what you have fixed.
If I know what to expect as a difference it is easier to make
comparative tests.
/Lars
Cool, thanks. As it stands, zyn's jack audio/midi is somewhat primitive. The
jack process callback works against a horrible, horrible hack in Master.cpp.
Also, the code attempts to piggyback jack midi on top of the audio's process
callback, complete with it's own need for a mutex lock.
I've split off the jack midi into a separate entity, which sets up it own
connection to jack, and thus gets it's own process callback that just deals
with midi.
I've seriously reworked the jack audio driver. The process callback
now directly calls the Master.cpp function formerly known as AudioOut().
I've renamed it MasterAudio(), in line with it's accompanying comment -
"Master audio out (the final sound)".
Having to acquire the master processing lock in order for the callback to
pick up the samples is problematic. Rather than throwing in a ringbuffer,
I'm currently trying a little experiment. The audio callback makes just
three attempts to get a lock using trylock. If it gets it, everything is
fine.
If it doesn't acquire the lock, then it simply feeds jack with the resident
set of samples currently in the buffers. My theory there is that repeating
256 samples might be a softer error than feeding 256 silent samples to jack.
From my observations, it doesn't actually miss the
lock all that often.
Cpu usage seems light enough, and jack audio does seem to be improved. The
Alsa audio also seems promising. I'm keen to see someone else's assessment,
maybe I'm just kidding myself.
And I'm dealing with Linux, so don't expect good things with a Windows build
for example.
For what it actually adds, the patch is ridiculously huge. One of the very
real problems with the zyn code is the complete absence of whitespace and
rational indentation. 25 years ago I used to be able to read (and write)
code like that, but not any more. Nowadays, I can't even look at code like
that without compulsively adjusting the whitespace - one of my many little
ocd's :-(.
cheers, Cal
6:12 p.m.
On Sat, Aug 1, 2009 at 5:04 AM, cal<cal(a)graggrag.com> wrote:
Cool, thanks. As it stands, zyn's jack audio/midi
is somewhat primitive. The
jack process callback works against a horrible, horrible hack in Master.cpp.
Also, the code attempts to piggyback jack midi on top of the audio's process
callback, complete with it's own need for a mutex lock.
on some level, this is correct. JACK MIDI arrives in the same callback
as audio. in this respect, JACK MIDI is entirely different from other
MIDI APIs that deliver MIDI in a way that is dissassociated from audio
i/o.
I've split off the jack midi into a separate
entity, which sets up it own
connection to jack, and thus gets it's own process callback that just deals
with midi.
you've just destroyed the entire goal of JACK MIDI :)
I've seriously reworked the jack audio driver. The
process callback
now directly calls the Master.cpp function formerly known as AudioOut().
I've renamed it MasterAudio(), in line with it's accompanying comment -
"Master audio out (the final sound)".
Having to acquire the master processing lock in order for the callback to
pick up the samples is problematic. Rather than throwing in a ringbuffer,
I'm currently trying a little experiment. The audio callback makes just
three attempts to get a lock using trylock. If it gets it, everything is
fine.
If it doesn't acquire the lock, then it simply feeds jack with the resident
set of samples currently in the buffers. My theory there is that repeating
256 samples might be a softer error than feeding 256 silent samples to jack.
From my observations, it doesn't actually miss the lock all that often.
how often is "not all that often" ?
8:52 a.m.
cal wrote:
There's an experimental patch against the 2.4.0
release tarball at
<http://www.graggrag.com/?q=node/19>.
I played a bit with it, and it seems to work fine. I only selected
patches and played them on the keyboard, though. Someone (Will Godfrey,
perhaps) should stress test it with heavy load and see wht happens.
A thing that struck me as odd: Why do I have to specify my jack
buffersize, when zyn obviously knows what it should be:
[atte@vestbjerg ~]$ zynaddsubfx
<snip>
Sample Rate = 48000
Sound Buffer Size = 256 samples
Internal latency = 5.3 ms
ADsynth Oscil.Size = 1024 samples
AudioOut, zynNframes 256, zynSamplerate 48000
Error, zynNframes 256 != jack buffer size 128 => bad
Error, failed to open audio out on 'default'
So instead of me having to go "zynaddsubfx -b 128", the program should
know that the only sane buffersize with the running jack server is 128
and then use that.
I'm not sure if this behaviour is new, but I don't seem to remember this...
--
Atte
http://atte.dk http://modlys.dk http://virb.com/atte
9:03 a.m.
On Sat, 01 Aug 2009 12:52:44 +0200
Atte Andre Jensen <atte.jensen(a)gmail.com> wrote:
cal wrote:
I think there always was an external and an internal buffersize. But
yeah, it should be trivial to get jacks buffersize and use it.
Less trivial might be on-the-fly buffersize changes. Those are possible
since a long time but few applications support it currently, in
hydrogen for example it only works in very recent svn revisions.
This is not a deal breaker, sane and stable jack performance is far
more important.
Philipp
There's an experimental patch against the
2.4.0 release tarball at
<http://www.graggrag.com/?q=node/19>.
I played a bit with it, and it seems to work fine. I only selected
patches and played them on the keyboard, though. Someone (Will
Godfrey, perhaps) should stress test it with heavy load and see wht
happens.
A thing that struck me as odd: Why do I have to specify my jack
buffersize, when zyn obviously knows what it should be:
[atte@vestbjerg ~]$ zynaddsubfx
<snip>
Sample Rate = 48000
Sound Buffer Size = 256 samples
Internal latency = 5.3 ms
ADsynth Oscil.Size = 1024 samples
AudioOut, zynNframes 256, zynSamplerate 48000
Error, zynNframes 256 != jack buffer size 128 => bad
Error, failed to open audio out on 'default'
So instead of me having to go "zynaddsubfx -b 128", the program
should know that the only sane buffersize with the running jack
server is 128 and then use that.
I'm not sure if this behaviour is new, but I don't seem to remember
this...
11 a.m.
On Sat, Aug 01, 2009 at 12:52:44PM +0200, Atte Andre Jensen wrote:
So instead of me having to go "zynaddsubfx -b
128", the program should
know that the only sane buffersize with the running jack server is 128
and then use that.
ISTR (but it's years ago - since the LAC where Zyn was
first presented) that Zyn uses FFT based processing for
some of its algorithms. If this is the case and the FFT
size has to be some minimal value then there's a problem
if the jack period is shorter. It's possible to solve
this by using additional RT-threads that run at lower
priority than Jack's one, this is what jconv does. In
some cases there are other solutions as well.
Anyway in a properly designed Jack app there should be
no such thing as a global process lock. The first step
would seem to find out why it is necessary, and try
to find an architecture that doesn't need it .
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
11:16 a.m.
Fons Adriaensen wrote:
ISTR (but it's years ago - since the LAC where Zyn
was
first presented) that Zyn uses FFT based processing for
some of its algorithms. If this is the case and the FFT
size has to be some minimal value then there's a problem
if the jack period is shorter.
I don't know if such a problem is the case with zyn, but when I specify
the -b 128 everything is just fine. To me it simply seems like a
user-unfriendly design, where you must specify the buffer size on the
command line, when theres actually one on possibility, namely the buffer
size of the running jack server.
I imagine this stems from zyn starting as a non-jack application,
probably even OSS only, where it makes sense to specify the buffer size
on the command line. Then I imagine that later when jack support was
hacked into the thing, the code wasn't really structured in a way to
make it easy to detect buffersize of a running jack server. This would
fit with what cal wrote: "I've certainly thought about how to relocate
zyn's application of those parameters until after initialising the
audio, but I haven't tackled that monster yet".
--
Atte
http://atte.dk http://modlys.dk http://virb.com/atte
2:47 p.m.
Fons Adriaensen wrote:
On Sat, Aug 01, 2009 at 12:52:44PM +0200, Atte Andre
Jensen wrote:
A true story. I'm way too old to even consider re-engineering zyn though,
so I'm prepared to settle for just keeping a favourite "vintage" app
useable.
cheers.
So instead of me having to go "zynaddsubfx
-b 128", the program should
know that the only sane buffersize with the running jack server is 128
and then use that.
ISTR (but it's years ago - since the LAC where Zyn was
first presented) that Zyn uses FFT based processing for
some of its algorithms. If this is the case and the FFT
size has to be some minimal value then there's a problem
if the jack period is shorter. It's possible to solve
this by using additional RT-threads that run at lower
priority than Jack's one, this is what jconv does. In
some cases there are other solutions as well.
Anyway in a properly designed Jack app there should be
no such thing as a global process lock. The first step
would seem to find out why it is necessary, and try
to find an architecture that doesn't need it .
Ciao,
12:50 p.m.
On Sat, 01 Aug 2009 12:52:44 +0200
Atte Andre Jensen <atte.jensen(a)gmail.com> wrote:
cal wrote:
I've marked this for having a look at, but I've had a series of IT
problems lately :(
--
Will J Godfrey
http://www.musically.me.uk
There's an experimental patch against the
2.4.0 release tarball at
<http://www.graggrag.com/?q=node/19>.
I played a bit with it, and it seems to work fine. I only selected
patches and played them on the keyboard, though. Someone (Will Godfrey,
perhaps) should stress test it with heavy load and see wht happens.
5:55 p.m.
On Sat, 01 Aug 2009 14:37:52 +1000
cal <cal(a)graggrag.com> wrote:
ZynAddSubFX is a truly amazing piece of work, an
amazing little synth.
Sadly, when it comes to jack operation it's a case of flawed genius.
There's an experimental patch against the 2.4.0 release tarball at
<http://www.graggrag.com/?q=node/19>.
I've restructured the audio and midi drivers, and added Alsa audio. It
builds with multiple audio/midi options, nominate what to actually use
via command line parameters. The build options and default choices are
set as per normal in Makefile.inc.
If any mildly adventurous zyn enthusiast cared to try a build && run, I'd
appreciate 25 words or less on the experience. At the moment I'm mostly
interested in jack audio/midi performance.
The patch applies from the ZynAddSubFX-2.4.0/ directory, then off to src/
to edit Makefile.inc and build as usual.
cheers, Cal
Got things sorted a bit now and gave this a try. Seems to patch cleanly
but won't compile.
I've put the last part of the report as an attachment (so that claws
doesn't try to reformat it!)
--
Will J Godfrey
http://www.musically.me.uk
2 Aug
2 Aug
1 a.m.
Folderol wrote:
On Sat, 01 Aug 2009 14:37:52 +1000
cal <cal(a)graggrag.com> wrote:
A header include issue it would seem. I notice gcc 4.2 in there, whereas
I'm on 4.3. I'll see if I can figure out how to solve it.
cheers, Cal
[ ... stuff]
Got things sorted a bit now and gave this a try. Seems to patch cleanly
but won't compile.
I've put the last part of the report as an attachment (so that claws
doesn't try to reformat it!)
7:34 p.m.
I am on gcc 4.2.2 and I get the same error.
/Lars
2009/8/1 Folderol <folderol(a)ukfsn.org>
On Sat, 01 Aug 2009 14:37:52 +1000
cal <cal(a)graggrag.com> wrote:
ZynAddSubFX is a truly amazing piece of work, an
amazing little synth.
Sadly, when it comes to jack operation it's a case of flawed genius.
There's an experimental patch against the 2.4.0 release tarball at
<http://www.graggrag.com/?q=node/19>.
I've restructured the audio and midi drivers, and added Alsa audio. It
builds with multiple audio/midi options, nominate what to actually use
via command line parameters. The build options and default choices are
set as per normal in Makefile.inc.
If any mildly adventurous zyn enthusiast cared to try a build && run, I'd
appreciate 25 words or less on the experience. At the moment I'm mostly
interested in jack audio/midi performance.
The patch applies from the ZynAddSubFX-2.4.0/ directory, then off to src/
to edit Makefile.inc and build as usual.
cheers, Cal
Got things sorted a bit now and gave this a try. Seems to patch cleanly
but won't compile.
I've put the last part of the report as an attachment (so that claws
doesn't try to reformat it!)
--
Will J Godfrey
http://www.musically.me.uk
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
6 Aug
6 Aug
7:31 a.m.
New subject: Zyn and the art of software maintenance [nee art of jack audio/midi]
cal wrote:
[ ... ]
There's an experimental patch against the 2.4.0
release tarball at
<http://www.graggrag.com/?q=node/19>.
I've restructured the audio and midi drivers, and added Alsa audio. It
builds with multiple audio/midi options, nominate what to actually use
via command line parameters. The build options and default choices are
set as per normal in Makefile.inc.
If any mildly adventurous zyn enthusiast cared to try a build && run, I'd
appreciate 25 words or less on the experience. At the moment I'm mostly
interested in jack audio/midi performance.
The patch applies from the ZynAddSubFX-2.4.0/ directory, then off to src/
to edit Makefile.inc and build as usual.
In the spirit of Yoshimi I have battled the monster.
zyn2.4.0++.2.patch.bz2 @ <http://www.graggrag.com/?q=node/19>
random notes ...
- the samplerate and buffer size reported by jack are now used by zyn. Alsa
& OSS audio still rely on zyn settings or command line parameters.
- initialization of Master moved from the constructor to Master::Init(). Apart
from enabling the jack thing, this hints at possibilities for re-initializing
without restarting the app. Re-init audio, re-init Master, and act like
nothing's wrong. Haven't thought too much about how to put that together
though.
- the jack midi remains a total contradiction of the fundamental principles
of Jack midi :-(. I think there's potential for conformance, but for now
I'll plead a case for special dispensation.
- builds with g++ 4.2 (for me at least)
- less experimental perhaps, but little mushroom clouds are still quite
possible.
cheers. Cal
5589
days inactive
5594
days old
linux-audio-user@lists.linuxaudio.org
13 comments
7 participants
participants (7)
-
Atte Andre Jensen -
cal -
Folderol -
Fons Adriaensen -
hollunder＠gmx.at -
Lars-Erik Helander -
Paul Davis