linuxsampler-devel — This list is for discussing LinuxSampler development issues and ideas

Re: [Linuxsampler-devel] LinuxSampler BUGS to fix (Christian & others)

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

On Sun, 2003-11-23 at 13:40, Christian Schoenebeck wrote:
> Es geschah am Donnerstag, 20. November 2003 03:08 als Mark Knecht schrieb:
> > I do not see much difference in terms of segfaults from the previous
> > rev. It still dies after one or two notes as it did before. (Get up to a
> > high voice count, let the voices die away so it all goes back to zero,
> > then play a few notes and it crashes.)
> 
> Sorry for answering that late; been very busy. You might have noticed, that 
> I've commited a couple of fixes in the last days. The segfault issue you 
> described should also be fixed now.

Seems to be. Please see the response I wrote to Benno's email earlier
today.
> 
> > Anyway, with the MIDI input working again I played a bit with the new
> > code. I don't have much good to report really. It does work now, in the
> > sense that I get audio, but my sense (just from playing) was that
> > somehow the sample choices it's making from a multi-sample/note library
> > are not right. I got some very strange effects playing hard and soft.
> 
> Yeah, Benno already told me that. Maybe there's a problem in the resolution of 
> the sample.
> 
> > To study this a bit I ran the Bardstown piano through the MIDI velocity
> > tests I had done earlier. This was the MIDI file supplied by Warren
> > Trachtman. What I found was that volume is not varied at all over the
> > complete range of MIDI velocities, while there seemed to be only 3
> > samples chosen out of the 4 in the library. This would seem to be a bug
> > to me, but possibly not...
> 
> Ok, the latter might be a bug, I will check that. Regarding the 
> velocity<->volume mapping this is not yet implemented, but I will add that 
> next.
> 

Great!

Re: [Linuxsampler-devel] new CVS version: some fixes

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

Oh, one strange thing. If I kill the xterm that LS is running in, using
the window decoration 'X', LS is not killed and continues to work even
with no terminal.

It doesn't matter, really, but I thought I should report it.

Cheers,
Mark

On Sun, 2003-11-23 at 14:56, Mark Knecht wrote:
> On Sun, 2003-11-23 at 13:28, be...@ga... wrote:
> > Christian made some fixes and has uploaded a new version:
> > 
> > * rewrote sustain pedal handling: instead of just queuing the note-offs I added
> > a sustain pointer for each midi key which starts to point to the first active
> > voice on the respective key and increments to the next voice on the key when a
> > note-off arrived, the release velocity value will immediately be stored in the
> > respective voice object (this also fixes the segmentation fault issue when the
> > sustain pool was full).
> > 
> > Now the streams are deallocated properly.
> > There is still a small bug that occurs when you max out polyphony.
> > (probably in the disk stream, we will look into).
> > 
> > Mark can you test if this version works for you ?
> > 
> > cheers,
> > Benno
> > http://www.linuxsampler.org
> > 
> 
> Hi Benno,
>    Was sitting here working on a problem for Jaroslav. This sounded like
> a nice break and a bit more fun.
> 
>    This version is much better behaved. It's no longer complaining about
> lack of memory when I load this big library, and so far I cannot crash
> it with the sustain pedal like before. Here's what it looks like when I
> start it. I've made no changes to the code, so you are handling the
> plughw thing yourself now in code. Thanks.
> 
>    Can I request that we maybe get a MIDI input hookup on the LS command
> line so that I can test LS without my having to use kaconnect? That
> would make things a bit easier.
> 
> Wizard root # linuxsampler --numfragments 2 --gig
> /mnt/samples/Gigs/Pianos/Bardstown\ Audio/The\ Bosendorfer\ Imperial\
> Grand\ Version\ 2.2.gig 
> Initializing audio output...Warning: your soundcard doesn't support
> chosen hardware parameters; trying to compensate support lack with
> plughw...OK
> Loading gig file...OK
> Caching initial samples...OK
> Starting disk thread...OK
> Starting MIDI in thread...OK
> Starting audio thread...OK
> LinuxSampler initialization completed.
> Voices: 000 (Max: 000) Streams: 000 (Max: 000, Unused: 100)
> 
> At this point I can play and I get voices OK. It seems that this version
> of the code maxes out at 64 voices, as far as I can tell, however the
> streams seem to be set up for 100.
> 
> No free voice!
> No free voice!
> No free voice!
> No free voice!ax: 064) Streams: 062 (Max: 064, Unused: 038)
> No free voice!
> No free voice!
> No free voice!
> 
> Note that the messages get overwritten in my xterm.
> 
> What exactly is a 'stream'? So far the stream number always equals the
> voice number.
> 
> Looking better all the time.
> 
> Mark

Re: [Linuxsampler-devel] new CVS version: some fixes

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

On Sun, 2003-11-23 at 13:28, be...@ga... wrote:
> Christian made some fixes and has uploaded a new version:
> 
> * rewrote sustain pedal handling: instead of just queuing the note-offs I added
> a sustain pointer for each midi key which starts to point to the first active
> voice on the respective key and increments to the next voice on the key when a
> note-off arrived, the release velocity value will immediately be stored in the
> respective voice object (this also fixes the segmentation fault issue when the
> sustain pool was full).
> 
> Now the streams are deallocated properly.
> There is still a small bug that occurs when you max out polyphony.
> (probably in the disk stream, we will look into).
> 
> Mark can you test if this version works for you ?
> 
> cheers,
> Benno
> http://www.linuxsampler.org
> 

Hi Benno,
   Was sitting here working on a problem for Jaroslav. This sounded like
a nice break and a bit more fun.

   This version is much better behaved. It's no longer complaining about
lack of memory when I load this big library, and so far I cannot crash
it with the sustain pedal like before. Here's what it looks like when I
start it. I've made no changes to the code, so you are handling the
plughw thing yourself now in code. Thanks.

   Can I request that we maybe get a MIDI input hookup on the LS command
line so that I can test LS without my having to use kaconnect? That
would make things a bit easier.

Wizard root # linuxsampler --numfragments 2 --gig
/mnt/samples/Gigs/Pianos/Bardstown\ Audio/The\ Bosendorfer\ Imperial\
Grand\ Version\ 2.2.gig 
Initializing audio output...Warning: your soundcard doesn't support
chosen hardware parameters; trying to compensate support lack with
plughw...OK
Loading gig file...OK
Caching initial samples...OK
Starting disk thread...OK
Starting MIDI in thread...OK
Starting audio thread...OK
LinuxSampler initialization completed.
Voices: 000 (Max: 000) Streams: 000 (Max: 000, Unused: 100)

At this point I can play and I get voices OK. It seems that this version
of the code maxes out at 64 voices, as far as I can tell, however the
streams seem to be set up for 100.

No free voice!
No free voice!
No free voice!
No free voice!ax: 064) Streams: 062 (Max: 064, Unused: 038)
No free voice!
No free voice!
No free voice!

Note that the messages get overwritten in my xterm.

What exactly is a 'stream'? So far the stream number always equals the
voice number.

Looking better all the time.

Mark

Re: [Linuxsampler-devel] LinuxSampler BUGS to fix (Christian & others)

[Christian S. <chr...@ep...>]

Es geschah am Donnerstag, 20. November 2003 03:08 als Mark Knecht schrieb:
> I do not see much difference in terms of segfaults from the previous
> rev. It still dies after one or two notes as it did before. (Get up to a
> high voice count, let the voices die away so it all goes back to zero,
> then play a few notes and it crashes.)

Sorry for answering that late; been very busy. You might have noticed, that 
I've commited a couple of fixes in the last days. The segfault issue you 
described should also be fixed now.

> Anyway, with the MIDI input working again I played a bit with the new
> code. I don't have much good to report really. It does work now, in the
> sense that I get audio, but my sense (just from playing) was that
> somehow the sample choices it's making from a multi-sample/note library
> are not right. I got some very strange effects playing hard and soft.

Yeah, Benno already told me that. Maybe there's a problem in the resolution of 
the sample.

> To study this a bit I ran the Bardstown piano through the MIDI velocity
> tests I had done earlier. This was the MIDI file supplied by Warren
> Trachtman. What I found was that volume is not varied at all over the
> complete range of MIDI velocities, while there seemed to be only 3
> samples chosen out of the 4 in the library. This would seem to be a bug
> to me, but possibly not...

Ok, the latter might be a bug, I will check that. Regarding the 
velocity<->volume mapping this is not yet implemented, but I will add that 
next.

CU
Christian

[Linuxsampler-devel] new CVS version: some fixes

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

Christian made some fixes and has uploaded a new version:

* rewrote sustain pedal handling: instead of just queuing the note-offs I added
a sustain pointer for each midi key which starts to point to the first active
voice on the respective key and increments to the next voice on the key when a
note-off arrived, the release velocity value will immediately be stored in the
respective voice object (this also fixes the segmentation fault issue when the
sustain pool was full).

Now the streams are deallocated properly.
There is still a small bug that occurs when you max out polyphony.
(probably in the disk stream, we will look into).

Mark can you test if this version works for you ?

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





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

Re: [Linuxsampler-devel] filter analysis intial results

[Josh G. <jg...@us...>]

On Thu, 2003-11-20 at 07:10, Steve Harris wrote:
> I have some likly values for the cutoff - it looks like:
> 
> cutoff (Hz) = CC val * 40.0;
> 
> Which is supprising as its both quite limited (max 5080) and linear. What
> does DLS define it as?
> 

>From what I can tell looking at the DLS2 specs, the filter cutoff
frequency is in 32-bit absolute pitch units which looks like:

Absolute Pitch = (1200 * log2(f/440) + 6900) * 65536

f is the frequency of interest. Each abs pitch unit represents 1/65536
cents.

How this gets mapped to a MIDI controller depends on what connection
blocks you create. Connection blocks are pretty much just like SoundFont
modulators, except in DLS they are used for all parameter settings (if
its just a fixed value with no control sources, the controls sources
will be constant). A connection block looks like:

uint16 Source
uint16 Control
uint16 Destination
uint16 Transform
uint32 Scale

Source/Control specifies 2 sources of control (there is a nice table of
all of these numbers in the spec, includes CC controllers as well as
synthesis signal inputs like Envelopes and LFOs). The Destination
specifies what parameter a connection block is applied to (gain,
panning, LFO parameter, EG parameter, Filter, etc). The Transform can be
None, Concave, Convex or Switch. The final parameter Scale, specifies
the actual value to multiply with the Source/Control and Transform
parameters. Pretty flexible parameter format, the one unfortunate part
of the spec is that they define a set of "supported" connection block
sources/destinations. This may just mean what should be supported
minimum to be considered DLS compliant, but I'm not sure. The format
itself would allow for some cool things though (like controlling panning
or filter resonance with envelopes or LFOs).

> I dont have an analysis of the filter type yet, but I'm working on it.
> 
> - Steve

I'm sure thats more info than you wanted, but I just couldn't help
myself, I like the DLS2 format a lot. Cheers.
	Josh Green

RE: [Linuxsampler-devel] cvs access

[Tobias E. <t.e...@gm...>]

> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of
> Robert Jonsson
> Sent: Thursday, November 20, 2003 9:43 PM
> To: t.e...@gm...; lin...@li...
> Subject: Re: [Linuxsampler-devel] cvs access
> 
> 
> Hi Tobias,
> 
> You probably tried the cvs at sourceforge, unfortunately it's 
> not the right 
> cvs-tree, perhaps it should be marked somehow...
> 
> The right tree is at:
> 
> cvs -z3 
> -d:pserver:ano...@cv...:/home/schropp/linuxsampler 
> co linuxsampler 
> (check the homepage)

Ok - thanks a lot - checking out resulted in some more exciting stuff
now ;-)

Tobias 

Re: [Linuxsampler-devel] cvs access

[Robert J. <rob...@da...>]

Hi Tobias,

You probably tried the cvs at sourceforge, unfortunately it's not the right 
cvs-tree, perhaps it should be marked somehow...

The right tree is at:

cvs -z3 -d:pserver:ano...@cv...:/home/schropp/linuxsampler 
co linuxsampler 
(check the homepage)

/Robert


Thursday 20 November 2003 20.29 skrev Tobias Erichsen:
> Hi everyone,
>
> I've just checked out the module "linuxsampler" with my WinCVS from the
> sourceforge cvs-server to do a little browsing over the source. Uunfortu-
> nately I seem to have checked out a version which contains next to
> nothing...
> perhaps someone could give me pointer if i need to check out some specific
> revision/tag to get anything of the current development?
>
> Tobias
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

[Linuxsampler-devel] cvs access

[Tobias E. <t.e...@gm...>]

Hi everyone,

I've just checked out the module "linuxsampler" with my WinCVS from the
sourceforge cvs-server to do a little browsing over the source. Uunfortu-
nately I seem to have checked out a version which contains next to
nothing...
perhaps someone could give me pointer if i need to check out some specific
revision/tag to get anything of the current development?

Tobias

[Linuxsampler-devel] filter analysis intial results

[Steve H. <S.W...@ec...>]

I have some likly values for the cutoff - it looks like:

cutoff (Hz) = CC val * 40.0;

Which is supprising as its both quite limited (max 5080) and linear. What
does DLS define it as?

I dont have an analysis of the filter type yet, but I'm working on it.

- Steve

Re: [Linuxsampler-devel] LinuxSampler BUGS to fix (Christian & others)

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

On Tue, 2003-11-18 at 15:28, Christian Schoenebeck wrote:

> > Christian any idea why on Mark's box the current CVS does not work ?
> 
> Nope, I don't really think it has to do something with my changes. Mark, have 
> you removed the sources and tried a clean new checkout? Perhaps you just 
> messed up something accidently.

Apparently I did mess something up. As I said, I was using my USB
devices over the weekend to test my dad's new machine, so I had
unplugged by MidiSport. When I was done I plugged it back in, but
apparently plugged it into a different USB port. For whatever reason,
the device was 'recognized' as a USB device, and using usbview I could
see all the config data inside of it, but for some reason it doesn't get
linked to the usb-audio driver when plugged into that port.

I eventually noticed that the usb-audio driver, while loaded, said it
was unused, so I plugged the MidiSport into a different USB port and
then the MidiSport linked itself to usb-audio and started working again.

Why should this be? Why doesn't Linux treat this stuff the same?

I do not see much difference in terms of segfaults from the previous
rev. It still dies after one or two notes as it did before. (Get up to a
high voice count, let the voices die away so it all goes back to zero,
then play a few notes and it crashes.)

Anyway, with the MIDI input working again I played a bit with the new
code. I don't have much good to report really. It does work now, in the
sense that I get audio, but my sense (just from playing) was that
somehow the sample choices it's making from a multi-sample/note library
are not right. I got some very strange effects playing hard and soft.

To study this a bit I ran the Bardstown piano through the MIDI velocity
tests I had done earlier. This was the MIDI file supplied by Warren
Trachtman. What I found was that volume is not varied at all over the
complete range of MIDI velocities, while there seemed to be only 3
samples chosen out of the 4 in the library. This would seem to be a bug
to me, but possibly not...

I do not know if you are even attempting to chose samples based on
velocity, nor do I know if you are trying to control volume at all based
on velocity, so I won't call these results a bug until you report back
what I should be getting.

I hope this data helps.

Re: [Linuxsampler-devel] LinuxSampler BUGS to fix (Christian & others)

[Christian S. <chr...@ep...>]

Es geschah am Dienstag, 18. November 2003 17:37 als be...@ga... schrieb:
> Yes,
> for example if I do the following: load the compressed piano GIG,
> press sustain and eat up all polyphony (64) until you get no free voice
> messages.
> Then let the voices decay till the samples end.
> Now start to hit keys again (with and without sustain pressed) and you
> will notice several streams will remain active even when no voices are
> played.
> At this point you get lots of "disktstream not ready in time" messages.
>
> Christian any idea what could cause this ?

It seems that those streams that weren't finished just in time remain waiting 
to be picked up by a voice. So the number of available streams gets smaller 
and smaller. Should be easy to fix it.

> Christian any idea why on Mark's box the current CVS does not work ?

Nope, I don't really think it has to do something with my changes. Mark, have 
you removed the sources and tried a clean new checkout? Perhaps you just 
messed up something accidently. If a clean checkout doesn't solve it, you can 
checkout the old version by:

cvs -z3 -d:pserver:ano...@cv...:/home/schropp/linuxsampler 
-D 15-Nov-03 co linuxsampler

(one line of course)

CU
Christian

Re: [Linuxsampler-devel] LinuxSampler BUGS to fix (Christian & others)

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

On Tue, 2003-11-18 at 08:37, be...@ga... wrote:

> 
> Christian any idea why on Mark's box the current CVS does not work ?
> Mark can you elaborate ?

Benno,
   I don't know what to tell you. I built the code. It seemed to build
without any errors. It starts up looking completely normal. When the gig
file is loaded and I see the line where you count voices and streams I
then hook up my keyboard to LS using kaconnect exactly as I did before.
It acts as if it's attached according to kaconnect. However I when I hit
keys on the keyboard I do not get any response from LS. The voices and
stream count remains at 0 and I get no audio. I did not save the
previous version of LS. I built over the top of that, so I lost that
executable for testing. How can I check out a certain date of LS to go
back and make sure this is really a code issue and not a problem on my
end?

   I do see MIDI event lights on the MidiSport 2x2 that is receiving
from the keyboard, so I assume they are getting to LS.I have no reason
to expect any big problems with the machine, however my dad was here
this weekend and I was using some of my USB devices on his new PC for
test purposes, so maybe there's something going on. I'll recheck for
loose cables and the like. Don't over react. It's likely something silly
that I did. (I do this sort of stuff more than occasionally!) ;-)

   BTW - I don't know who to lobby, but once again I'll cry out that
Alsa's user interface for MIDI devices is not user friendly. The idea
that we users should remember numbers instead of having tools like
kaconnect tell me which piece of hardware we're using and which soft
synth we're attaching to is just not nice and error prone. Why should LS
be 128:0. ZynAddSubFx at 129:0. Why should these numbers change from day
to day. This just doesn't work well at all when I'm using 4 MIDI ports
and 3 soft synths. I think that when we introduce the power of LS to the
PC and Mac worlds it would be wise to have a solution to this.

- Mark


> 
> 
> cheers,
> Benno
> http://www.linuxsampler.org
> 
> 
> -------------------------------------------------
> This mail sent through http://www.gardena.net
> 
> 
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

[Linuxsampler-devel] Free 80MB piano .GIG file for testing

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

Here you can find a free 80MB (40MB .zip file) piano .GIG file.
The samples are taken from the MIS piano but only one layer (ff notes).

(the file is FreePiano.zip)

http://www.alchemystudio.it/FreeSamples/FreeSamplesIndex_en.htm

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


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

Re: [Linuxsampler-devel] LinuxSampler BUGS to fix (Christian & others)

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

Scrive Christian Schoenebeck <chr...@ep...>:

> Es geschah am Montag, 17. November 2003 12:40 als be...@ga... schrieb:
> > Download the latest CVS where Christian made some fixes that avoid
> > crashes and apply the above change.
> 
> There is still at least one nasty bug, I will have a look at it when I have 
> the time for it again (next couple of days).

Yes, 
for example if I do the following: load the compressed piano GIG,
press sustain and eat up all polyphony (64) until you get no free voice
messages.
Then let the voices decay till the samples end. 
Now start to hit keys again (with and without sustain pressed) and you
will notice several streams will remain active even when no voices are
played.
At this point you get lots of "disktstream not ready in time" messages.

Christian any idea what could cause this ?
I'm a bit busy this week so I cannot perform extensive debugging sessions.
Anyway the new ReleaseVoice() code looks fine (pVoiceSelf etc), 
good job Christian !

> 
> > Anyway LS currently uses a method to stream crompressed .GIG files which
> > is a bit suboptimal. Basically no caching of the decompressed stream is
> > performed so the decompressing is performed all the time (in the
> > low priority disk thread).
> > Anyway I'm unsure if caching would buy us anything because those samples
> > are so large that you could only cache small parts and playing dynamic
> > pieces you trigger a large number of the samples contained in the GIG so I
> > guess caching would be only a big coding work with maybe gaining only a
> few
> > % in terms of absolute performance.
> 
> It wouldn't be a good idea at all to cache it, and the decompression
> algorithm 
> is already quite optimal at least in the aspect that it's pure C++. Low level
> 
> optimization would make sense here, but that has to wait until the more 
> important things are done. Keep in mind: how many compressed gigs are out 
> there? Not many...

I agree on all the above, this is why I already said that the current
method we use is perfectly fine.

Christian any idea why on Mark's box the current CVS does not work ?
Mark can you elaborate ?


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


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

Re: [Linuxsampler-devel] LinuxSampler BUGS to fix (Christian & others)

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

On Mon, 2003-11-17 at 03:40, be...@ga... wrote:
> Scrive Mark Knecht <mar...@co...>:
> 
> The SustainedKeysPool FULL message is due to
> audiothread.cpp: line 40:
>    SustainedKeyPool = new RTELMemoryPool<sustained_key_t>(200);
> you must replace 200 with MAX_AUDIO_VOICES.
> There can be as much sustaned voices as there are voices.
> Download the latest CVS where Christian made some fixes that avoid
> crashes and apply the above change.
> Then set MAX_AUDIO_VOICES/STREAMS to 256, recompile and try to
> drive LS to 240-250 voices and look at the 'top' command how much
> CPU LS consumes. I'm curious :-)
> 

Sorry. This version does not work for me. It loads up but actls like
it's not receiving MIDI events and produces no audio.

- Mark

Re: [Linuxsampler-devel] LinuxSampler BUGS to fix (Christian & others)

[Christian S. <chr...@ep...>]

Es geschah am Montag, 17. November 2003 12:40 als be...@ga... schrieb:
> Download the latest CVS where Christian made some fixes that avoid
> crashes and apply the above change.

There is still at least one nasty bug, I will have a look at it when I have 
the time for it again (next couple of days).

> Anyway LS currently uses a method to stream crompressed .GIG files which
> is a bit suboptimal. Basically no caching of the decompressed stream is
> performed so the decompressing is performed all the time (in the
> low priority disk thread).
> Anyway I'm unsure if caching would buy us anything because those samples
> are so large that you could only cache small parts and playing dynamic
> pieces you trigger a large number of the samples contained in the GIG so I
> guess caching would be only a big coding work with maybe gaining only a few
> % in terms of absolute performance.

It wouldn't be a good idea at all to cache it, and the decompression algorithm 
is already quite optimal at least in the aspect that it's pure C++. Low level 
optimization would make sense here, but that has to wait until the more 
important things are done. Keep in mind: how many compressed gigs are out 
there? Not many...

CU
Christian

Re: [Linuxsampler-devel] LinuxSampler BUGS to fix (Christian & others)

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

Scrive Mark Knecht <mar...@co...>:

The SustainedKeysPool FULL message is due to
audiothread.cpp: line 40:
   SustainedKeyPool = new RTELMemoryPool<sustained_key_t>(200);
you must replace 200 with MAX_AUDIO_VOICES.
There can be as much sustaned voices as there are voices.
Download the latest CVS where Christian made some fixes that avoid
crashes and apply the above change.
Then set MAX_AUDIO_VOICES/STREAMS to 256, recompile and try to
drive LS to 240-250 voices and look at the 'top' command how much
CPU LS consumes. I'm curious :-)



> On Sat, 2003-11-15 at 18:03, Christian Schoenebeck wrote:
> > Es geschah am Sonntag, 16. November 2003 00:15 als Mark Knecht schrieb:
> > > Sitting idle, on my Athlon-XP 2600+ with 512MB, LS is using 0.7%. Even
> > > banging away on it, but being careful not to use too many notes, it
> > > never gets above 5% on my machine. I don't think this means much, but
> > > it's a data point.
> > 
> > Benno is using a compressed gig whereas you most probably are using a
> normal 
> > one. That's the reason for the cpu usage difference.

Yes, plus the problems is even more visibile in my case because my CPU
is a bit slow.
Anyway LS currently uses a method to stream crompressed .GIG files which
is a bit suboptimal. Basically no caching of the decompressed stream is
performed so the decompressing is performed all the time (in the
low priority disk thread).
Anyway I'm unsure if caching would buy us anything because those samples are
so large that you could only cache small parts and playing dynamic pieces
you trigger a large number of the samples contained in the GIG so I guess
caching would be only a big coding work with maybe gaining only a few % in
terms of absolute performance.
Keep in mind that the decompression is performed in the low priority thread
which means the audio engine does not get slow down by the streaming task.
As long as the CPU is being able to keep up with the load things will be 
perfectly fine.
As said above when playing a real, dynamic (in terms of MIDI velocity) piece
even the optimized engine would probably make little use of the caching.


> 
> This only popped up when trying to allow 256 voices on 512MB. I will
> grant you that my GSt machine has 768MB and is only allowed to do 96
> voices, so I'm not overly concerned, but I am curious what's driving
> this. What's the equation for how much memory is required by LS right
> now?

The equation is simple:
audiothread.h: #define NUM_RAM_PRELOAD_SAMPLES 32768

when you have mono samples, each sample contained in the GIG lib consumes
64KB (32768 x 16bit) in memory. In case of stereo samples its 128KB.

diskthread.h:#define STREAM_BUFFER_SIZE 131072
When you define the max number of voices
(MAX_AUDIO_VOICES) you consume
MAX_AUDIO_VOICES*STREAM_BUFFER_SIZE*2 (2 because samples are 16bit).
So in case of 256 voices and the default STREAM_BUFFER_SIZE of 131072

256*131072*2 = 64MB

So perhaps these additional 64MB did not fit in your RAM anymore.
Keep in mind that the voice buffers are not that big, most of the RAM
is consumed by the sample beginnings preloaded in RAM.
The number to tweak is NUM_RAM_PRELOAD_SAMPLES (you increased it to 65536,
thus experienced the mlockall problems).
Try to lower it to 50k, 40k or even 32k. (although 32k is a bit low when
streaming that much voices).
Keep in mind NI Kontakt users reported being forced to use 150k samples of 
preload in some case in order to achieve stable operation.
Of course this means you need a tons of RAM.
Our numbers are actually quite good.

> 
> And can't one simply allocate less memory and take a risk of drop outs
> because we have less of the sample in memory? 

Yes this is the NUM_RAM_PRELOAD_SAMPLES value.
The smaller this value the bigger the risk of dropouts during high 
polyphony passages.
But as you have seen even with 32k (GSt uses 32k samples too) we can
achieve a polyphony of 100+ voices ( = 200 in GSt's termionology) quite
reliably. The chopin demo as run with 4msec latency and did not show a single
dropout. And I rendered it to disk while surfing the net with Mozilla while
 my box was swapping nicely :-)

Or are there hints in the
> gig file that are telling you what to do? I should try some smaller
> libraries and see what happens.

No the hints are not in the GIG file, each disk based samples uses his
own settings (and GSt is still the best windows sampler in terms of streaming
because of its releatively efficient engine due to the kernel based engine).
From reading various forums, the GSt's competition (Halion,Kontakt etc) is not
able to deliver the same numbers because using the Windows APIs is slower
than using the iron directly so they must compensate the inefficiencies
by using large sample preload sizes. But this means being able to load
less samples in RAM.
64bit is still an illusion on Windows so the upper RAM limits are 1-1.5GB.
see here: http://www.pcworld.com/news/article/0,aid,112749,pg,6,00.asp
This is why with GSt you can preload more samples on the same box than
using the other windows softsamplers (which are better in terms of VSTi
integration, more flexible, more effects etc).
So for those needing many sample libraries preloaded (for large orchestral
stuff) GSt still have some advantages.

PS: saw an interview with Hans Zimmer on the german ZDF TV channel.
They did show his studio (but not the GSt farm :-) ), kinda cool guy.

We must all work hard so that LS lands in his studio too,
you know we all need to fuel our personal egos :-))

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



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

Re: [Linuxsampler-devel] LinuxSampler BUGS to fix (Christian & others)

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

A few notes:
Marks said he gets the SustainedKeyPool full message
I know the reason of the bug:
audiothread.cpp, line 41:
    SustainedKeyPool=new RTELMemoryPool<sustained_key_t>(200);

Actually it should be

SustainedKeyPool=new RTELMemoryPool<sustained_key_t>(MAX_AUDIO_VOICES);
Scrive Mark Knecht <mar...@co...>:

Because there can be as much as sustained voices as there are voices.
Mark I suggest you to check out the latest CVS where Christian made
some fixes like deleting the voice from the on/sustained voice list and
other other bug fixed that caused crashed.
Then add the above fix, increase the MAX VOICE/STREAMS defines and 
drive it up to 240 voices and show the CPU usage with 'top'.
I'm curious :-)


> > 
> > Benno is using a compressed gig whereas you most probably are using a
> normal 
> > one. That's the reason for the cpu usage difference.

Yes, plus my CPU is dog slow. So the difference is even more visible.
Actually LS uses a bit a suboptimal method when streaming compressed .GIG files.
Basically the streaming engine decompressed the streams in real time and
is not caching them if you play the same notes.
Perhaps caching would be 


> 
> OK.
> 
> > 
> > > > You could try to load up LS to 256 voices and see how much CPU
> > > > it uses.
> > > > but in that case increase the preload size too
> > > > audiothread.h:#define NUM_RAM_PRELOAD_SAMPLES 65536
> > >
> > > Tried it. The program dies somewhere around 120-140 voices complaining:
> > >
> > > Wizard root # linuxsampler --numfragments 2 --gig
> > > /mnt/samples/Gigs/Pianos/Bardstown\ Audio/The\ Bosendorfer\ Imperial\
> > > Grand\ Version\ 2.2.gig
> > > Loading gig file...OK
> > > WARNING, can't mlockall() memory!: Cannot allocate memory
> > > WARNING, can't mlockall() memory!: Cannot allocate memory
> > 
> > That's a sign of low free memory when it's unable to lock it.
> 
> This only popped up when trying to allow 256 voices on 512MB. I will
> grant you that my GSt machine has 768MB and is only allowed to do 96
> voices, so I'm not overly concerned, but I am curious what's driving
> this. What's the equation for how much memory is required by LS right
> now?
> 
> And can't one simply allocate less memory and take a risk of drop outs
> because we have less of the sample in memory? Or are there hints in the
> gig file that are telling you what to do? I should try some smaller
> libraries and see what happens.
> 
> - Mark
> 
> 
> 
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
> 




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

Re: [Linuxsampler-devel] LinuxSampler BUGS to fix (Christian & others)

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

On Sat, 2003-11-15 at 18:03, Christian Schoenebeck wrote:
> Es geschah am Sonntag, 16. November 2003 00:15 als Mark Knecht schrieb:
> > Sitting idle, on my Athlon-XP 2600+ with 512MB, LS is using 0.7%. Even
> > banging away on it, but being careful not to use too many notes, it
> > never gets above 5% on my machine. I don't think this means much, but
> > it's a data point.
> 
> Benno is using a compressed gig whereas you most probably are using a normal 
> one. That's the reason for the cpu usage difference.

OK.

> 
> > > You could try to load up LS to 256 voices and see how much CPU
> > > it uses.
> > > but in that case increase the preload size too
> > > audiothread.h:#define NUM_RAM_PRELOAD_SAMPLES 65536
> >
> > Tried it. The program dies somewhere around 120-140 voices complaining:
> >
> > Wizard root # linuxsampler --numfragments 2 --gig
> > /mnt/samples/Gigs/Pianos/Bardstown\ Audio/The\ Bosendorfer\ Imperial\
> > Grand\ Version\ 2.2.gig
> > Loading gig file...OK
> > WARNING, can't mlockall() memory!: Cannot allocate memory
> > WARNING, can't mlockall() memory!: Cannot allocate memory
> 
> That's a sign of low free memory when it's unable to lock it.

This only popped up when trying to allow 256 voices on 512MB. I will
grant you that my GSt machine has 768MB and is only allowed to do 96
voices, so I'm not overly concerned, but I am curious what's driving
this. What's the equation for how much memory is required by LS right
now?

And can't one simply allocate less memory and take a risk of drop outs
because we have less of the sample in memory? Or are there hints in the
gig file that are telling you what to do? I should try some smaller
libraries and see what happens.

- Mark

Re: [Linuxsampler-devel] LinuxSampler BUGS to fix (Christian & others)

[Christian S. <chr...@ep...>]

Es geschah am Sonntag, 16. November 2003 00:15 als Mark Knecht schrieb:
> On Sat, 2003-11-15 at 13:57, be...@ga... wrote:
> > Scrive Mark Knecht <mar...@co...>:
> > >    I am not hearing the high pitched noise on my system,
> > > and I'm never
> > > getting very high on CPU usage. I never see about about 3% on gkrellm
> > > even at close to 64 voices.
> >
> > Cool, for completeness use 'top' too its CPU usage measurement is
> > convincing IMHO (look at the CPU usage of the linuxsampler process)
>
> Sitting idle, on my Athlon-XP 2600+ with 512MB, LS is using 0.7%. Even
> banging away on it, but being careful not to use too many notes, it
> never gets above 5% on my machine. I don't think this means much, but
> it's a data point.

Benno is using a compressed gig whereas you most probably are using a normal 
one. That's the reason for the cpu usage difference.

> > You could try to load up LS to 256 voices and see how much CPU
> > it uses.
> > but in that case increase the preload size too
> > audiothread.h:#define NUM_RAM_PRELOAD_SAMPLES 65536
>
> Tried it. The program dies somewhere around 120-140 voices complaining:
>
> Wizard root # linuxsampler --numfragments 2 --gig
> /mnt/samples/Gigs/Pianos/Bardstown\ Audio/The\ Bosendorfer\ Imperial\
> Grand\ Version\ 2.2.gig
> Loading gig file...OK
> WARNING, can't mlockall() memory!: Cannot allocate memory
> WARNING, can't mlockall() memory!: Cannot allocate memory

That's a sign of low free memory when it's unable to lock it.

> LinuxSampler initialization completed.
> WARNING, can't mlockall() memory!: Cannot allocate memory
> ERROR: SustainedKeyPool FULL ! exiting
> Wizard root #
>
> The code in audiothread.cpp that generates this message says /FIX ME/ so
> I guess you need to. ;-)

Actually exiting at that point doesn't make sense anyway Benno, so I'll remove 
it.

> > Keep in mind that there are linked lists holding the current on notes
> > (voice) and the currently sustained notes.
> > When a voice fades out due to the sample ending the corresponding voice
> > is not yet removed from those lists.
> > Thus the next time you press a key (or relase the pedal) it could
> > crash the engine because it is accessing to voices used twice etc.
> > It's a known bug but the important thing was getting sustain working for
> > now.
>
> OK. Let me know when you've fixed it and I'll look again.

I will fix that.

> > > Request: Could you possibly put the plughw:0 hack instructions in a
> > > README that gets downloaded with the code?
> >
> > Yes we should add a --alsadevice option too.
> > Plus Christian on his delta 1010 was not able to make plughw work
> > so probably we need a special hw:0 routine for his delta
> > (otherwise LS does not work on his workstation connected to the
> > midi keyboard).

plughw works now with my Delta 1010; it wasn't plughw itself but the 
combination of alsa calls that preceded the snd_pcm_open() call. I will 
implement automatic fallback to plughw if the sound card lacks to support one 
the parameters. I will print out a warning in that case and this way no hack 
or additional parameter is needed. Anybody against that?

> ;-) Well, add Jack support while you're at it. ;-)
>
> But, seriously, we all know this needs to be a Jack device, doesn't it?
> Is it difficult to make the change?

At least not on my priority list at the moment (even though it wouldn't be 
much work). But if anybody has the time and will for it, just place the jack 
code into audioio.cpp and don't forget to send us your patch! :)

CU
Christian

Re: [Linuxsampler-devel] LinuxSampler BUGS to fix (Christian & others)

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

On Sat, 2003-11-15 at 13:57, be...@ga... wrote:
> Scrive Mark Knecht <mar...@co...>:

> >    I am not hearing the high pitched noise on my system,
> > and I'm never
> > getting very high on CPU usage. I never see about about 3% on gkrellm
> > even at close to 64 voices.
> 
> Cool, for completeness use 'top' too its CPU usage measurement is 
> convincing IMHO (look at the CPU usage of the linuxsampler process)

Sitting idle, on my Athlon-XP 2600+ with 512MB, LS is using 0.7%. Even
banging away on it, but being careful not to use too many notes, it
never gets above 5% on my machine. I don't think this means much, but
it's a data point.


> it's just a define, no limitation :-)
> for example for 256 voices define:
> 
> audiothread.h:#define MAX_AUDIO_VOICES  256
> diskthread.h:#define MAX_INPUT_STREAMS 256
> 
> and recompile.
> 
> You could try to load up LS to 256 voices and see how much CPU
> it uses.
> but in that case increase the preload size too
> audiothread.h:#define NUM_RAM_PRELOAD_SAMPLES 65536 

Tried it. The program dies somewhere around 120-140 voices complaining:

Wizard root # linuxsampler --numfragments 2 --gig
/mnt/samples/Gigs/Pianos/Bardstown\ Audio/The\ Bosendorfer\ Imperial\
Grand\ Version\ 2.2.gig 
Loading gig file...OK
WARNING, can't mlockall() memory!: Cannot allocate memory
WARNING, can't mlockall() memory!: Cannot allocate memory
LinuxSampler initialization completed.
WARNING, can't mlockall() memory!: Cannot allocate memory
ERROR: SustainedKeyPool FULL ! exiting
Wizard root # 

The code in audiothread.cpp that generates this message says /FIX ME/ so
I guess you need to. ;-)

Before it crashed I was still only seeing about 4-5% on the main LS
thread. I cannot watch them all and play at the same time. 


> 
> Keep in mind that there are linked lists holding the current on notes (voice)
> and the currently sustained notes.
> When a voice fades out due to the sample ending the corresponding voice
> is not yet removed from those lists.
> Thus the next time you press a key (or relase the pedal) it could
> crash the engine because it is accessing to voices used twice etc.
> It's a known bug but the important thing was getting sustain working for
> now.

OK. Let me know when you've fixed it and I'll look again.

> 
> 
> > 
> > Request: Could you possibly put the plughw:0 hack instructions in a
> > README that gets downloaded with the code?
> 
> Yes we should add a --alsadevice option too.
> Plus Christian on his delta 1010 was not able to make plughw work
> so probably we need a special hw:0 routine for his delta
> (otherwise LS does not work on his workstation connected to the 
> midi keyboard).
> 

;-) Well, add Jack support while you're at it. ;-)

But, seriously, we all know this needs to be a Jack device, doesn't it?
Is it difficult to make the change?

Re: [Linuxsampler-devel] LinuxSampler BUGS to fix (Christian & others)

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

Scrive Mark Knecht <mar...@co...>:

> Hi Benno,
>    I built CVS this morning and gave it a shot. Sustain is working.
> Still big clicks on each key release, so I guess no release samples or
> default envelope yet. (I think that's expected, but just in case it's
> supposed to be there I'll report it's not working for me.)

No envelopes implemented yet. So click is normal.

> 
>    This version seems to load very much faster for me. Have you done
> something in that area?

It's probably because I set the preload size to 32k samples (instead
of the previous 64k). This is because I was developing on a 256MB box
which was not able to load a big piano GIG with 64k preloading.
The fun thing is that even with this relatively short preloading time.
(0.7sec). the heavy sustain piano MIDI file was able to play
100 stereo voices without getting dropouts.
I heard in NI Kontakt for stable operation sometimes you need 600KB (150K
samples) of preload ! :-)

> 
>    I am not hearing the high pitched noise on my system,
> and I'm never
> getting very high on CPU usage. I never see about about 3% on gkrellm
> even at close to 64 voices.

Cool, for completeness use 'top' too its CPU usage measurement is 
convincing IMHO (look at the CPU usage of the linuxsampler process)

> 
>    I do see the segfault when I get to 64 voices. (I thought LS wasn't
> going to have a voice limitation?)

it's just a define, no limitation :-)
for example for 256 voices define:

audiothread.h:#define MAX_AUDIO_VOICES  256
diskthread.h:#define MAX_INPUT_STREAMS 256

and recompile.

You could try to load up LS to 256 voices and see how much CPU
it uses.
but in that case increase the preload size too
audiothread.h:#define NUM_RAM_PRELOAD_SAMPLES 65536 


> 
>    I am also seeing a stranger, and different segfault. I hold the
> sustain pedal and just arpeggiate a C major chord and let the voices
> build up, but only to about 55-60 voices. Next I hold the sustain pedal
> and let the voice count decay back to 0. Now, with the sustain pedal
> still held, I start the arpeggio again, it segfaults immediately and
> differently:

Keep in mind that there are linked lists holding the current on notes (voice)
and the currently sustained notes.
When a voice fades out due to the sample ending the corresponding voice
is not yet removed from those lists.
Thus the next time you press a key (or relase the pedal) it could
crash the engine because it is accessing to voices used twice etc.
It's a known bug but the important thing was getting sustain working for
now.


> 
> Request: Could you possibly put the plughw:0 hack instructions in a
> README that gets downloaded with the code?

Yes we should add a --alsadevice option too.
Plus Christian on his delta 1010 was not able to make plughw work
so probably we need a special hw:0 routine for his delta
(otherwise LS does not work on his workstation connected to the 
midi keyboard).

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


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

Re: [Linuxsampler-devel] LinuxSampler BUGS to fix (Christian & others)

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

Hi Benno,
   I built CVS this morning and gave it a shot. Sustain is working.
Still big clicks on each key release, so I guess no release samples or
default envelope yet. (I think that's expected, but just in case it's
supposed to be there I'll report it's not working for me.)

   This version seems to load very much faster for me. Have you done
something in that area?

   I am not hearing the high pitched noise on my system, and I'm never
getting very high on CPU usage. I never see about about 3% on gkrellm
even at close to 64 voices.

   I do see the segfault when I get to 64 voices. (I thought LS wasn't
going to have a voice limitation?)

   I am also seeing a stranger, and different segfault. I hold the
sustain pedal and just arpeggiate a C major chord and let the voices
build up, but only to about 55-60 voices. Next I hold the sustain pedal
and let the voice count decay back to 0. Now, with the sustain pedal
still held, I start the arpeggio again, it segfaults immediately and
differently:

The first is a voice overload segfault:

Wizard root # linuxsampler --numfragments 2 --gig
/mnt/samples/Gigs/Pianos/Bardstown\ Audio/The\ Bosendorfer\ Imperial\
Grand\ Version\ 2.2.gig 
Loading gig file...OK
LinuxSampler initialization completed.
Segmentation faultms: 060  

This one is the other segfault:

Wizard root # linuxsampler --numfragments 2 --gig
/mnt/samples/Gigs/Pianos/Bardstown\ Audio/The\ Bosendorfer\ Imperial\
Grand\ Version\ 2.2.gig 
Loading gig file...OK
LinuxSampler initialization completed.
Segmentation faultms: 014  
Wizard root # 

Request: Could you possibly put the plughw:0 hack instructions in a
README that gets downloaded with the code?

Thanks,
Mark


On Sat, 2003-11-15 at 09:39, be...@ga... wrote:
> Christian told me that he wants to begin to implement the event system 
> but I'd prefer that we fix a few bugs first, otherwise it will harder and
> harder to find them.
> 
> - LS crashes when the maximum voice count is achieved
> - when you hold a voices till the sample terminates you hear a continuing high
> pitched noise. I guess this is the buffer of the voice still being mixed
> to the sum buffer. Plus in that case the CPU usage goes up.
> - sometimes a voice gets cut off and only the RAM part is played.
> 
> So folks (particularly Christian) check out the latest CVS and start finding
> the bugs. (I have no time for the next few days)_
> 
> regarding the event system I will post a message tonite or tomorrow because
> I have a few questions for David how to optimize the system.
> 
> regarding the polyphony of my VIA with crappy FPU machine:
> I tested a piano .MID file that makes heavy use of sustain pedal. 
> My box is able to keep up with peaks of 100 stereo voices.
> = 200 voices expressed gigasampler terminology :-)
> Better not imagine what an Athlon 3000 can deliver :-)
> So basically it means that a mini-itx VIA box has enough horsepower
> to ne turned into a high polyphony, high quality piano expander.
> :-)
> 
> Let me know (on the list) if you find the bugs mentioned above, and
> then let's start with the event sysyem.
> 
> cheers,
> Benno
> http://www.linuxsampler.org
> 
> 
> -------------------------------------------------
> This mail sent through http://www.gardena.net
> 
> 
> -------------------------------------------------------
> This SF. Net email is sponsored by: GoToMyPC
> GoToMyPC is the fast, easy and secure way to access your computer from
> any Web browser or wireless device. Click here to Try it Free!
> https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

[Linuxsampler-devel] LinuxSampler BUGS to fix (Christian & others)

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

Christian told me that he wants to begin to implement the event system 
but I'd prefer that we fix a few bugs first, otherwise it will harder and
harder to find them.

- LS crashes when the maximum voice count is achieved
- when you hold a voices till the sample terminates you hear a continuing high
pitched noise. I guess this is the buffer of the voice still being mixed
to the sum buffer. Plus in that case the CPU usage goes up.
- sometimes a voice gets cut off and only the RAM part is played.

So folks (particularly Christian) check out the latest CVS and start finding
the bugs. (I have no time for the next few days)_

regarding the event system I will post a message tonite or tomorrow because
I have a few questions for David how to optimize the system.

regarding the polyphony of my VIA with crappy FPU machine:
I tested a piano .MID file that makes heavy use of sustain pedal. 
My box is able to keep up with peaks of 100 stereo voices.
= 200 voices expressed gigasampler terminology :-)
Better not imagine what an Athlon 3000 can deliver :-)
So basically it means that a mini-itx VIA box has enough horsepower
to ne turned into a high polyphony, high quality piano expander.
:-)

Let me know (on the list) if you find the bugs mentioned above, and
then let's start with the event sysyem.

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


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