On Freitag, 9. Februar 2018 19:36:19 CET Thomas Howe wrote: > I tried setting the maximum number of voices and disk streams to 1000 each > and this has helped a lot with one sample library (Maestro Concert Grand > v2). There are still occasional note drop outs, but only in extreme > circumstances, and no more xruns.
The xruns you got are most probably because your system is not configured to be real-time stable. And considering the very small period size you want to achieve, makes this configuration task even more challenging. Please note though that configuring a real-time stable system goes beyond the scope of this list. I am sure you find newbie howto's for that on the net or ask on the web forum or on the LAD mailing list for help on that topic. > I store the sample libraries in RAM to avoid disk speed problems. Maybe the > RAM isn't fast enough, or pitch-shifting (for the Salamander Grand Piano > v3) is causing ‘disk stream’ errors? I'm also running Jack at a higher Very unlikely. > Regarding the voice stealing cut-offs, have I got this right? If it turns > out to be impossible for me to get full polyphony at a lower buffer size > without xruns, I would need to set a voice limit. Reaching the voice limit > set in linuxsampler causes clicks, so I'd need this to be done through an > external MIDI voice limiting program sending note off messages when the > limit is reached. I might also need to modify the release samples in cases > like the Salamander Grand which has a slightly percussive release sound. Or you simply decrease the value of the compile time option EG_MIN_RELEASE_TIME to your period size, like I already told you in the previous email. There are plenty of experiments you could try out, but in the end the easiest solution is to simply configure your audio session with 1ms latency which works right out of the box. I mean it depends whether you really just want to make some theoretical experiments there, or whether you are seeking for a practical solution. Because in practice it is quite unlikely that you can feel the latency difference between an audio period duration of 0.6ms vs. 1ms. Plus in practice the various hardware components involved (i.e. your MIDI keyboard) often add latencies of several ms and people don't even realize that. You should also be aware that the smaller the audio period size, the higher the CPU overhead will be. So CPU utilization grows significantly more than anti-propopertional the lower you set the perdiod size. And in practice the negative impact of the latter is usually much higher to the user than the advantage you get by gaining 0.5ms latency. > htop reports that only one of the linuxsampler threads runs at realtime > priority by default, so I'll experiment with setting the others to realtime > priority too. The priority has nothing to do with that. The disk thread is most of the time waiting for I/O to complete and modifying the priority will not change that. > Also, linuxsampler asked me to report this (I think number of voices and > disk streams was set to 200?): I also explained that to you in the previous email already as well: you always have to set max streams higher than max. voices, otherwise it will lead to exactly what you just encountered. CU Christian ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linuxsampler-devel mailing list Linuxsampler-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
