Re: [Linuxsampler-devel] [ANNOUNCE] QSampler 0.0.1 released!

[<be...@ga...>]

Scrive Rui Nuno Capela <rn...@rn...>:
 
> 
> Sometimes I get a very similar problems when loading some instrument files
> too. However I always manage for them to show up correctly only after a
> second try (via channel setup dialog). Bear in mind that the file may load
> correctly on LS, but QS always fails to get it to a OK response from it,
> at least whithin the allowed time.
> 
> I suspect this is due to the long time these gigs take to load by
> linuxsampler, and the qsampler timeout interval is way too short for it
> (500ms is the default, you may try to set it longer). Of course, this
> varies with the system where you're running QS and LS (if not the same).
> 
> In my limited experience however, this kind of behaviour only tends to
> happen the very first time that particular file is loaded. If some time
> later, loading the very same files, is almost instantly.
> 
> Is it a matter of cache-on-demand from linuxsampler server?

it's not cache on demand it's the linux file cache that if you have
enough RAM caches the sections that LS preloads so loading of even
a big GIG file (eg a 1.5GB piano which preloads 100-200MB loads in a couple of
secsthe second time you load it).

Regarding the timeout in QS, I think we need an approache where the
user is informed about the progress of loading since with very big instruments
it can take a while, especially if the disk is not that fast.
The ideal would be if the LSCP command LOAD INSTRUMENT would
not only return OK after the loading is completed but
a sequence of percentage numbers separated by \n
eg 
client: LOAD INSTRUMENT .....
LS:
0
1
2
.....
99
100
OK

That way the client could show a progress bar during loading so the
users always know what's going on. Other softsamplers do that too.
Regarding the server side implementation, since LS knows how many
samples an instrument preloads it's just a matter of
returning a sequence of:

percentage=(100 * sample_index_being_loaded) / total_samples;

in that way QS should timeout only if it does not get new percentage
infos for 10-20 secs. 



> 
> In my ignorance, this seems that the stream count reported by LS is
> showing out the total number of stream buffers allocated since the start
> of the channel. The count never shrinks. Strangely enough, this isn't
> always true. Some other times that I could not determine how or when, both
> numbers seems to play very well. Beats me :)

I did not try it yet so I cannot comment but I think it's a server side
problem.


> 
> IIUC this problem occurs when linuxsampler is killed abruptally and the
> listener socket is not being closed nicely and is kept lingering around
> for some time, until the kernel decides to shutting it down. Other that LS
> crashing for other reason, hitting Ctrl-C on the console where LS was
> started is prone for this to happen, at least on my linux boxes. Perhaps a
> signal handler is not being correctly trapped on LS?
> 
> OTOH the 2 minute timeout might be a kernel/tcp-stack parameter that I
> don't remember right now (somewhere accessible under /proc :) but better
> yet, one should try to terminate LS with something in the lines of `kill
> <pid>` or `killall linuxsampler` instead of just Ctrl-C.

Yes, it's not a problem of LS it's an issue of the TCP/IP stack of Linux
which waits a 1-2min before closing the socket if it was shutdown
uncleanly.
If the signal 15 handler of LS is closing it correctly then
a 
killall lt-linuxsampler 
should do it.

cheers,
Benno
http://www.linuxsampler.org


-------------------------------------------------
This mail sent through http://www.gardena.net