Jack thread terminates if synth.effects-channels and/or synth.audio-channels are used within a config file #724
Comments
|
You may only place
No. It's not supported and fluidsynth is telling you:
It's not impossible. Just use the dedicated commandline flags, either
Where is that "crash" here? Jack only kicks us out of its processing loop and fluidsynth remains usable - at least for me. I agree, we should provide better user feedback in this case. But I don't see anything else we can do here. |
Yes, that's the behaviour I detected.
Yeah, using fluidsynth command line works, but I didn't find any way to do something like that using Probably
It is a "crash" in the sense that synth GUIs like Anyway, I just added a PR that should be detecting this problem in advance and printing some warnings: #725 Yet, IMHO, the best would be to let the config file to be able of setting those parameters, either parsing the set commands from it before calling: Or by adding an update method that would allow to dynamically change the number of audio channels. |
In qsynth you just click on Setup > Audio. In this dialog, you can set up the number of channels accordingly. After closing the dialog, qsynth destroys the synth and audio-driver and recreates them.
Setting up audio channels requires memory allocation. There is no way we can do this on-the-fly when the synth is already running. It would interfere with concurrent rendering calls. That's impossible.
Possible, theoretically. One would need to parse the file twice (which is ugly), break the existing API by uncluttering the command handler from the objects it requires for its creation while taking huge care to not break any existing functionality. Incredibly time-consuming, and not very beneficial in the end. |
I'm currently debugging the issue there. I was assuming that this would be due to the same issue as reported on this issue, , but it is a different one. It seems that there are two problems at
So, The net effect is that, if the number of audio channels is bigger than 2, it gets a Jack terminate message (only displayed on its message log window): Such problems initially seemed to be related to
True, but, it would be possible to re-size the buffer when the synth is idle. Btw, in the specific case of set commands from config files, the problem is that the parsing order is racy. What it does is:
If, at step (2), any command change the non-realtime settings from fluid_synth, things break. No idea how easy would be to implement it, but a possible approach would be to split
IMHO, passing such settings via command line args is a lot uglier :-) :
I see the point. |
The synth is stateless. It is always "ready-to-render". If you run the fluidsynth executable via cmdline, the synth always renders silence, so it's always busy (as soon as the audio-driver is created). Even if there were an "idle" state and you decide to tear down the channels and re-create them, the synth may start rendering again at any time, even if you are still busy doing this kind of "construction works". One would need synchronization here, and this means the synth would not be real-time safe anymore. So no, it's not possible.
Yes, that's clear to me. But it's the best order we can get without breaking other things. We've been through this pain several times already.
That "minimal set" is a fully configured synth. You can put note and CC events in a configuration file as well, configure MIDI router rules, etc. So a half-complete-throw-away-synth is not sufficient.
Well... that's the idea of UIs like qsynth. Alternatively, write that commandline into a shell file or use an alias. The soundfonts can be safely placed into the config file btw. |
Your idea of splitting In extern fluid_cmd_handler_t *new_fluid_cmd_handler2(fluid_synth_t *synth, fluid_midi_router_t *router, fluid_settings_t* settings);
preliminary_handler = new_fluid_cmd_handler2(NULL, NULL, settings);
// parse all set commands:
fluid_source(preliminary_handler, cfg_file);
// continue initializing...
the_final_real_handler = new_fluid_cmd_handler(synth, router);
// parse the entire file again, even the set commands (they won't have changed since the parsing from above)
fluid_source(the_final_real_handler, cfg_file);
// do rest of fluidsynth initialization...One would only need to add this new function This should be super simple to do and quick as well. You're welcome to draft a PR for that. Currently, I have a few other points on my agenda. |
Yeah, I can work on something like that. In a matter of fact, I did an experiment like that earlier today: There is one issue on this hack, that you mentioned: it needs to be a little bit smarter, in order to avoid creating some symbols: I suspect it shouldn't be hard to change this hack to the approach you suggested. On an OOT comment, this was what I cooked in order to fix multi-channel support with Jack on Qsynth: |
Added a patch series solving it at PR #737. |
FluidSynth version
Describe the bug
When either one of the options bellow:
Are used within a config file, the Jack Kthread terminates, causing
fluidsynthto silently crash. When this bug happens, it is not possible anymore to manually adjust the connection graph withqjackctl, or to usefluidsynth.This bug also affects
qsynth, making impossible to use it with more than 2 stereo channel outputs.Expected behavior
Fluidsynthshould be able to accept changing the number of audio and effect channels via configuration settings.Steps to reproduce
Create a
configfile with:Call
fluidsynth -v -f config. The result is:Additional context
The problem is related to the
callbackcall at:fluid_jack_driver_process()function, as this quickhack prevents Jack thread to stop:
With this quick hack,
fluidsynthnow returns:The text was updated successfully, but these errors were encountered: