Total Stream / voice count

[ccherrett]

Hi,

I am running a gentoo 64 build with fresh repository compiles of libgig, linuxsampler, gigedit, qsampler, liblscp and a binary of Fantasia

I have 4GB of RAM on an am2 duo core 4800 with maudio 2496

I am trying to load many instruments at once through linuxsampler. I am putting them all on channel ALL and using channel routing to output them to ardour.

It seems that I am maxing my stream at 64 voices. However it appears that my system can handle a lot more than that according to the loads I see in qjackctl.

Could it be that samples need to be loaded on thier own channels? If I do that I am not sure how to get them into ardour. It seems the default ardour reads from linuxsampler is to only load from channel 1. I know that this is a lack of understanding on my part but I would like to learn

So if it is possible to increase the voices coming out of ardour please let me know.

Thanks
Chris Cherrett

[ccherrett]

I just reread an email from Christian and it states the following:

The first thing you can tweak of course is the amount of sample points to be precached in RAM by the sampler, because that's what usually takes the most. Unfortunately this yet a compile time option:

./configure --enable-preload-samples=VALUE

but as the amount of max voices and disk streams, this is highly on our TODO list to become a runtime parameter.

If this means what I think it means then I hope I can:

./configure --enable-preload-samples=128

I will try........

[ccherrett]

I found the following while tweeking the gentoo ebuild:

--enable-max-streams <- the default is 90

--enable-max-voices <- the default is 64

I am going to up the max streams to 256 and max voices to 200.

the configure file states that the max streams should be larger then the max voices.

I am going to set up a use flag called high performance and set all this up at once.

Any help would be appreciated!

[ccherrett]

Ok,

max streams is set to 400 and max voices is set to 360. All seems well!

The only thing I think I see needed here is to max my mobo out to 8GB of RAM. I am using 2.5 out of 4GB. I see my cpus are only at 20% each and everything else looks stable. I think I should be able to load a big part of the orchestra at once.

I really do love using this system

Thank you very much!

[dahnielson]

I don't know if this is possible in the current version, but it would be a great feature when running orchestral libraries: It would be great to temporarily "disable" an instrument so that it gets unloaded but can be "enabled" and reloaded with just a click on a button in the GUI. That way it would be possible to set up a full orchestra even if it's not possible to have all instruments loaded at once.

[Alex]

Ccherrett, i've done the same, with a 4gb amd64 x2 5600+ box running 1 system and two sample hds. (7200, 16mb cache.)

The manual compile had the same result for me, freeing up a lot of resource, in excess of anything i'd been able to achieve with GS to such a degree, that I continue to be astonished.
Yes, Christian has indicated he's looking at a runtime option which will greatly increase the speed at which we can adjust voice count on the fly according to the project at hand, and of course, negate the need to recompile each time.

I'm thoroughly pleased to hear you're enjoying yourself, and if you go down the 8gb route, come back here and let us know how you fared. We'd be interested to know!

Alex.

[Alex]

I don't know if this is possible in the current version, but it would be a great feature when running orchestral libraries: It would be great to temporarily "disable" an instrument so that it gets unloaded but can be "enabled" and reloaded with just a click on a button in the GUI. That way it would be possible to set up a full orchestra even if it's not possible to have all instruments loaded at once.

Great idea, Anders. A 'freeze' in effect.

With 4gb of ram, and nearly 3gb of that allocated in memlock, on a dual core machine, i've compiled for 600 voices, and currently use an orchestral template of 160 channels and counting. So there's plenty of scope for growth.
Add the function you've suggested, and we could load a lot more channels, 'freezing' the channels we don't normally use by default, and merely unfreeze them when needed.

Alex.

[ccherrett]

Alex,

Ah so you are the guy from the reactor forum? If so I have been telling people about your experience with Linux

Yes a runtime option is for sure the way to go. Anything that is machine specific should be a runtime option. Great to hear!

I am also very pleased to hear about your orchestral samples loading in 160 channels!

It would be amazing to load most of the instrument I have and just unfreezing when needed. That would make my life so much easier. Just load what is needed when needed on the fly.

What orchestral library or libraries do you use? I bought the VSL OPUS 1 and OPUS 2. I am very happy with the sound. the only problem is the lack of legatos outside of booting Windows the use The Performance Tool. I would love to hear your experience there!

As for going to 8GB. I can see that happening soon. I first need to prove to myself that it is needed. The processors are not maxing out and that is nice. I have the samples on a sata 2 500GB drive which seems to be helping.

I also tweeked jack tonight and things seem to be running better than before. 0 xruns after long periods of time. Even when I disconnect a program. Here is what I did according to the jack documentation:

<quote>

It has been found that mounting /tmp/jack as tmpfs (in RAM) solves problems that many people have experienced with xruns while using JACK. The solutions below help when your /tmp directory is mounted on a journalled filesystem. Just put this in your /etc/fstab

none /tmp/jack tmpfs defaults 0 0

There is also a compile option to enable JACK to place its FIFOs on a ram-based filesystem as follows:

# mkdir /mnt/ramfs

[edit /etc/fstab and add the following line]

none /mnt/ramfs tmpfs defaults 0 0

Then use --with-default-tmpdir=/mnt/ramfs to the JACK configure line when you build it. No clients need to be recompiled.

</quote>

My friend Andrew and I rewrote some of my systems ebuild to accommodated automatically doing this via the the emerge --config {PACKAGE} command. I will try to submit it to allow the gentoo community access to it.

Talk to you all soon

[cuse]

ATM there's no "direct" way to enable / disable an instrument from a sampler channel, e.g. by simply clicking a "disable" button of one channel strip, but it would be easy to add, because that main functionality is already implemented in the engine. It is already used in the context of MIDI instrument mapping. No real user documentation about it yet, sorry, but here's some infos:

http://www.linuxsampler.org/api/draft-l ... INSTRUMENT

So for each entry in a MIDI instrument table you define, you can also define a load time strategy of either "ON_DEMAND", "ON_DEMAND_HOLD" or "PERSISTENT". So what you could do already now, is to establish such a MIDI instrument table (it can be stored in the LSCP session file as anything else), define your instruments with the "ON_DEMAND" option, establish empty channel strips and do the program change in your sequencer during your freeze process.