#42 Midi Ringbuffer full error - Bad Behavior on ProgramChange

[lieven]

When I run zynaddsubfx with -I alsa, after a very short time (10-20 secs)
I get this error from jack:

"Jack reports error: jack_client_thread zombified - exiting from JACK"

and after that a lot of these errors from Zynaddsubfx:

"ERROR: Midi Ringbuffer is FULL"

I have been using zyn mostly with jack midi recently, so I don't know since when
this is happening. Something wrong in the new input output system?

I'm running uptodate arch linux, and zyn from latest git. I used seq24 to send
midi.

[Mark McCurry]

I have had zombie issues in the past, but everything seems to run fine for me in jack if some of the worst blocking operations are avoided (eg program change events).
If the jack thread dies and midi events are received then the ringbuffer that feeds the jack thread will overflow, hence the error message.

What latencies are you running with jack? (period, sample rate, buffer size)
Are you able to replicate the issue with any specific midi event?
How much cpu usage when it dies?
How many cores does your machine have?
You imply that this does not happen with jack midi, correct?

My first guess is that you are just hitting some of the uglyness of zyn, which stops things from executing in real time, but this may be a bug.
I typically operate -I alsa -O jack on a 64 bit arch system and only experience zombie issues when:
a) horrible non-realtime code is run
b) I set the latency too low
c) I run a silly number of notes on computationally expensive patches

[lieven]

Thanks for your hint!

I found that sending one program_change message to zyn
was the reason for this issue. After removing the program_change
zyn runs fine again. Shouldn't zynaddsubfx be able to just ignore
these messages if they are not used?

I would still consider this a serious bug, but maybe a new one should
be opened for this?

P.S. Sorry to get back to you so late...

Greetings

[Mark McCurry]

Well it does not ignore the program change, which is why there is an issue.
It handles the program change event in a stupid way though (which will make jack quite displeased).
I have a rough idea how to fix this one, but it would be implemented in a hacky manner if I attacked it now without adding some more infrastructure.
Now that I know this is the bug at hand I will be able to update when I have a chance to tackle it (and the title is updated).

I do not have a good idea of when I will have a chance to work out the fix, as much more of my time is being spent in grad school than expected, but this will be taken care of.

[Mark McCurry]

I'm quite happy to close this bug now.
After a good bit of reworking the swapping of patches have been reduced down to just simple pointer swaps, so lockless loads work great now.
The changes are not ready for merging with master at this point, but the patches needed to get zyn to handle program changes sanely will be in the abs branch of git tonight.
As for testing this I have instruments loading seamlessly while running on:
jackd -d alsa -r 48000 -p 32 -n 3

No xruns from changing instruments via MIDI or the UI (though my system gets fussy if you start playing more than a handful of notes at this point).

[lieven]

On Fri, Aug 16, 2013 at 09:00:48PM +0000, Mark McCurry wrote:

I'm quite happy to close this bug now.
After a good bit of reworking the swapping of patches have been reduced down to just simple pointer swaps, so lockless loads work great now.
The changes are not ready for merging with master at this point, but the patches needed to get zyn to handle program changes sanely will be in the abs branch of git tonight.
As for testing this I have instruments loading seamlessly while running on:
jackd -d alsa -r 48000 -p 32 -n 3

No xruns from changing instruments via MIDI or the UI (though my system gets fussy if you start playing more than a handful of notes at this point).

That is great news!
Thanks for fixing this...

lieven