Bug 11

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>
Status:	CLOSED FIXED
Severity:	normal
Priority:	P2
Version:	SVN Trunk
Hardware:	Other
OS:	Linux

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.