On 18/02/2026 16:15, Will Godfrey wrote:
If you first-time start Yoshimi Jack audio is first tried but if it is not
running Yoshimi will try to use ALSA.
Normally this is fine. However if the audio system is not available Yoshimi
then crashes, when it should run with no audio.
At that point, it saves a config/yoshimi.banks file consisting of just the
headers.
On 21/02/2026 22:13, Will Godfrey wrote:
A point I forgot to mention is that even one you have a valid file there,
trying to restart with an inactive sound card will again result in an empty
bank file.
The first issue that simply should not occur is the crash - it doesn't on
older versions of Yoshimi. However what also needs to be discovered is how
that disrupts the bank system, and also why this even empties a previously
correct file.
Hello Yoshimi-devs,
firstly, I'd like to apologise because it took me so long to look into that
problem. There were simply a number of different matters I had to deal with.
Working from the description given, it seems clear that this problem must
have been caused by a combination of recent changes amplifying each other.
- we made changes to the config
- we made the start-up / shutdown more consistent
- the Round-1 of the MXML changes introduced a XMLFile object, which
is always basically sane and can be written.
Now, from the fact that a bank file was written, we can conclude that
this can not be a "crash". So the only solution that remains is that
"Yoshimi was staging a strategic retreat".
And indeed, this directly shows us a code path, were the regular
shutdown hook runs before the SynthEngine was fully booted up.
The fix for that is straight forward: do not save a bank file
that was not initialised, which can be detected as an empty root map.
Which leaves us with the second question: why does the "Null backend"
did not kick in and allow a regular start-up? As it turns out, this
problem was caused by my changes to the start-up sequence, which I
made two years ago, to allow for bootstrapping a push-data connection
from core to the UI.
As such this is not a problem, but I took the opportunity to switch
the musicIO backends to automatic memory management with a shared-ptr.
And here is the trap: I forgot to clean the preceding client object
in the case when we go into the null backend, after a failed previous
attempt. We have stale state in that case, and this causes the function
MusicClient::open() to return false, erroneously, while in fact it should
return true at that point. It returns false, since the client object
from the preceding try is still there (it will be cleaned automatically later),
but this client can not be opened, and so the result is false.
The fix is also quite simple: clear the client object whenever
a "no backend" case shall be tested.
-- Hermann
PS: https://github.com/Yoshimi/yoshimi/pull/248
_______________________________________________
Yoshimi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
