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

[Rui N. C. <rn...@rn...>]

Hi Mark,

>
>     This is just a short report from the build I did yesterday. It was a
> Harry Potter day today with the kid so I'm just getting back to this
> now. (5PM here)
>

:-)

>
> 1) One repeatable failure I always get goes like this:
>
>     a) Create QSampler and a single channel. Set that channel up with a
> working gig on MIDI channel 1, in my case a drum gig, and then trigger
> it to make some sound.
>
>     b) Edit that channel in QS and switch the MIDI channel to channel 2.
> Try to trigger it. It doesn't sound.
>
>     c) Switch the channel back to channel 1. It still doesn't work.
>
>  From here I have to kill LS and start over with QS to get audio again.
>

Same here. But I usualy don't need to kill LS (or restart it if it's
launched whithin QS); in my tests, a channel reset should do the trick.
However I think the MIDI channel switching is currently flawed, as I get
only channel 1 to work at all (or 0 as for omni mode). Think this is a
well known issue of latest LS.

>
> 2) I'm gettting the left channel only on the version of LS on your web
> site. I need to review the archives to find the solution to that. IIRC
> there was a copy/paste problem in the code and solution posted. I'll
> check that afer I send this, but I report it just in case it's specific
> to my system.
>

No, it's just that bug of my linuxsampler build. Please try one of
yesterday's, where the volume slider would also been fixed
(http://www.rncbc.org/ls).

>
> 3) Some gigs that have always loaded under LS are not loading under
> QSampler. The Bardstown Bosendorfer piano is one. I have not yet checked
> whether they still load under LS or whether this is a QSampler problem
> only. Hopefully I can try that later tonight.
>

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?

>
> 4) There is a failure mode with this version of LS/QS having to do with
> tracking of voices. Sometimes the tools work correctly. The active voice
> count goes up and then dies out slowly back to 0. Other times it just
> keeps climbing. In the case where it keeps climbing then eventually
> LS/QS start failing. In the case where it goes back to 0 they seem to
> keep working just fine.
>

As mentioned before, the green numbers are for the current stream count /
voice count. I think it's the stream count (the one to left of the slash)
that is always growing. The voice count (the other one, on the right of
the slash) works fairly well, as one would expect at least.

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 :)

>
> 5) One other (probably) LS problem is that often I will kill LS with a
> Ctrl-C. At that point often I cannot restart LS. I get a message hat it
> cannot bind the server channel. (I think that's the message.) I have to
> wait about 2 minutes for some sort of timeout and then I can restart.
> This does not happen every time I kill LS, but it happens often.
>

I assume you're starting linuxsampler from outside of QS. You probably
know that it can be started locally, under the control of QS. That way LS
server starts automagically when QS starts, and stops accordingly. You can
even restart the server when you please, whithout leaving QS.

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.

>
>     I have run LS/QS for a couple of hours with Rosegarden. If I don't
> get the failure mode in #4 then things work pretty well, but due to #1 I
> Can only run a single channel in QS.
>

In time, all these issues will be narrowed out. But, bear with me: it will
not happen just by itself; it is after your unvaluable help that will make
it better.


>     Overall this is a big step forward for user types like me and I
> think it will lead to better testing over the next few months.
>
>     Thanks so much for doing this! Very cool!
>

Thaks for your report. Keep on.


Cheers.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...