|Summary:||device management in QSampler goes mad if timeout occured in liblscp|
|Product:||QSampler||Reporter:||Christian Schoenebeck <cuse>|
|Component:||qsampler||Assignee:||Rui Nuno Capela <rncbc>|
Description Christian Schoenebeck 2005-05-04 19:09:22 CEST
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.
Comment 1 Rui Nuno Capela 2005-05-05 11:46:51 CEST
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 :).
Comment 2 Christian Schoenebeck 2005-05-05 14:41:40 CEST
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. Not sure...
Comment 3 Rui Nuno Capela 2005-06-09 13:04:25 CEST
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.
Comment 4 Rui Nuno Capela 2005-07-21 15:55:37 CEST
This issue has now been assumed fixed.