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

[Mark K. <mk...@co...>]

Rui Nuno Capela wrote:
<SNIP>
Not messing with MIDI for now. Would certainly appreciate someone 
looking at this sooner vs. later, but I can wait.
<SNIP>

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

All fixed. Much better. Volume slider actually works very nicely in real 
time. I can trigger a note with a long decay and then raise and lower 
volume. Seems to work nicely. (What about a pan control?) ;-)

> 
> 
>>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.

I think Benno is right. It's the large gigs that never load for me. The 
small ones do what you say - sometimes don't load the first time then 
load fine the second time.

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

Actually this version of LS seems a bit better behaved, up to a point. 
The stream/voice counts seem to be doing as we expect. Start at 0 - 
climb - stop hitting notes - slowly back to 0.

What I'm noticing about the count not going back down is when I'm 
hitting some limit in LS. As I get up to about 40 streams & voices I 
start getting audio cutting in and out. Also the audio sounds like it's 
looping. When this starts happening, if I stop hitting notes and wait 
then LS recovers. (S/V count back to 0/0.) However, if I don't stop 
hitting notes then the S/V count keeps climbing, the audio stays messed 
up and if I go far enough LS just gets sort of hung. At that point it 
may recorver, or it may fail. (Fail == S/V count staying high and audio 
not working right.) I've had both happen.

> 
> 
>>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.

I didn't know I could run LS from within QS. I read it but it didn't 
register. That seems to work pretty nicely actually. All results above 
and below are done that way using the 6/6/04 version from your web site 
this morning. I haven't had the 2-minute timeout doing it this way. 
(yet...)

<SNIP>
> 
> Thaks for your report. Keep on.
> 

OK, so with the current versions things are working a bit better. Volume 
control works great. S/V count is a bit better.

Enhancement request - a command line option to make default channel 
audio connection with Alsa or Jack for this instance of QS.

qsampler -a {alsa:jack}


Problem Report - CPU usage - I'm apparently able to overrun my 3GHz 
machine with just a single note on the mouse. If I continually play a 
single note so that QS says I'm up to 43 voices, then gkrellm is showing 
CPU usage jumps up to 100%. Top shows about 90% of the CPU going to LS 
and 10% to QS. This only takes about 2-3 clicks per second and happens 
in about 15 seconds. I think something is really not right about this. 
There is no disk activity. The note is a cymbal crash which is probably 
100% in RAM.

Why should CPU usage be so high at this point?

The note I'm hitting has about a 7-8 second tail. If I hit a single note 
and watch LS then the S/V count goes to 1 and stays for 7-8 seconds 
before it drops back to 0.

In my mind, when I start hitting lots of the same note the ones I hit at 
t=0 should not be playing after t=9 but it appears to me that they are 
not being released by LS. At 2-3 notes/second I should never be able to 
make the S/V count go higher than 27 on this sample.

I bet when we figure this out LS will work better. (Assuming I'm not 
totally messed up and wrong about how it should operate!)

There was something else I was going to report or ask for but I cannot 
remember it right now.

Thanks,
Mark