FrancescoCeruti
commented
5 years ago Right now every MediaCue has it's own pipeline with it's own sink, in the case of the (gstreamer) jack-sink every instance is spawning it's own jack client, I can't change this behavior.
This problem can be solved by avoiding the "1-MediaCue = 1-Sink" situation, this require a redesign of the GStreamer backend.
s0600204
Currently, when LiSP is using Jack (instead of ALSA, or pulseaudio) LiSP (or the GStreamer backend) creates a new Jack-client for each media cue.
Unfortunately, Jack has a hardcoded maximum number of clients: 64 (https://github.com/jackaudio/jack2/blob/develop/common/JackConstants.h#L65).
This client limit does not just apply to LiSP, but is shared with other applications on the computer. This means that LiSP has a maximum limit of media cues: Jack's client limit minus however many other clients (from other applications or the computer's physical connections) are currently active. (Further media cues can be added to a showfile, but LiSP/GStreamer emits an error and the newly added cues are unplayable.)
For instance, I recently ran a show with 55 media cues. A quick check shows that I could have had a further four media cues without problems (so long as I had no other audio-emitting applications running), but a fifth would cause LiSP to complain that
GStreamer cannot open resource for writing- because Jack had come to its client limit.By comparison:
The Ardour approach is probably closer to what LiSP should do.
I don't know how easy this would be to achieve, but it's something that probably should be addressed, if not for 0.6, then for 0.7 or later.
(Issue can be duplicated by running LiSP with Jack, and adding media cues until one gets an error.)