Whenever a timeout occurs in liblscp during QSampler's device management
dialog, qsampler will continue trying to send very weird LSCP commands and will
finally crash after a while.
This usually happens on managing ALSA audio output devices and seems to be
caused by a long delay in Alsa's snd_card_next() call, which is used in
LiuxSampler's Alsa driver to determine all possible sound cards on the running
system. A temporary workaround is to raise the timout value in QSamplers
preferences, but this is not a solution as all liblscp functions are
synchronous and thus block the whole GUI process until the respective LSCP
command is finished. So the GUI becomes quite sluggish.
I'm currently investigating the root cause of this problem within ALSA. But
beside that root cause I would recommend to do an exceptional treatment on
those timeout events in qsampler, e.g. not continueing with the device
management LSCP command sequence whenever such a timeout occurs.
I'm considering to take the brute-force approach while on liblscp, regarding
these timeouts issue. I do hate do recognise that any LSCP command sequence go
astray whenever a timeout occurs, leaving the client out of sync regarding the
tcp stream (e.g. server just takes longer to respond to some LSCP command, the
client timeouts and issues another different command which ultimately receives
the wrong answer).
The "brute force approach" goes like shutting down the socket connection
whenever a timeout is detected on the client, and then reconnect. This approach
assumes that the server is able to listen and accept a new client connection,
even thought it is still processing a previous lengthy request (which results
will go straight to /dev/null anyway :).
I fear that approach (reconnecting) doesn't solve the problem at all. Because
the LSCP server is currently implemented as singleton. Only one connection is
served at the same time (FIFO). So your next command after a reconnection will
still wait for the old command sent before the reconnection to return. We
choses this design, because it reduced the effort of synchronization techniques
a lot (Mutex, etc.) and we thought it would be quite uncommon to send several
LSCP commands at the same time.
We could change that singleton design of course and allow the server to serve
multiple connections at the same time. But that reconnection brute force
approach is still suboptimal.
The best approach from my perspective would be to allow the liblscp calls to be
asynchronous. That way, the GUI would always be responsive, no matter how long
a command takes. But I guess this would mean a lot of work on QSampler side.
As of liblscp 0.3.0, a workaround has been taken forth to mitigate this timeout
flush idiosyncrasy: the receive buffer is now being flushed whenever any
transaction failure is detected due to a timeout.
This issue has now been assumed fixed.