Thank you for your reply!
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.
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
sample rate, but I'm guessing that resampling all the libraries to 96 kHz
would increase rather than decrease the total processing?
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.
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.
Also, linuxsampler asked me to report this (I think number of voices and
disk streams was set to 200?):
Jack: JackClient::ClientNotify ref = 11 name = LinSmPSR16 notify = 1
Jack: JackClient::RemoveClient name = LinSmPSR16, ref = 11
Jack: JackClient::kRemoveClient fName = LinuxSampler name = LinSmPSR16
Jack: JackClientSocket::Close
Jack: JackClientSocket::Close
Jack: JackLibClient::~JackLibClient
Jack: JackShmReadWritePtr1::~JackShmReadWritePtr1 11
Jack: Succeeded in unlocking 422 byte memory area
Jack: jack_client_close res = 0
Jack: JackClient::ClientNotify ref = 9 name = LinuxSampler notify = 18
Jack: JackClient::ClientNotify ref = 9 name = LinuxSampler notify = 18
04:57:29.542 Channel 1 Mute: 1.
No unused stream found (OrderID:128) - report if this happens, this is a
bug!
No unused stream found (OrderID:130) - report if this happens, this is a
bug!
Disk stream not available in time!
Disk stream not available in time!
No unused stream found (OrderID:170) - report if this happens, this is a
bug!
No unused stream found (OrderID:184) - report if this happens, this is a
bug!
No unused stream found (OrderID:190) - report if this happens, this is a
bug!
Disk stream not available in time!
No unused stream found (OrderID:4) - report if this happens, this is a bug!
Disk stream not available in time!
Disk stream not available in time!
No unused stream found (OrderID:25) - report if this happens, this is a bug!
Disk stream not available in time!
No unused stream found (OrderID:35) - report if this happens, this is a bug!
Disk stream not available in time!
Disk stream not available in time!
No unused stream found (OrderID:46) - report if this happens, this is a bug!
Disk stream not available in time!
I added a second instrument on the same channel, muted the first one, and
got a bunch of xruns while playing. I don't think I need multiple
linuxsampler instruments running at the same time, so this isn't really a
problem for me.
Tom
On 8 February 2018 at 18:18, Christian Schoenebeck <
schoeneb...@linuxsampler.org> wrote:
> On Donnerstag, 8. Februar 2018 16:00:53 CET Thomas Howe wrote:
> > Hi all,
> >
> > Please let me know if there's a better place to be sending these
> messages...
>
> The list is fine for that, it just became a bit more silent over here than
> it
> used to be. When it comes to newbie questions, those might probably quicker
> being answered on the web forum instead:
>
> https://bb.linuxsampler.org/
>
> > I think I've identified the problems a bit more clearly now:
> >
> > 0.0025 ms isn't a long enough fadout to prevent an audible click in some
> > cases, yet it is also too long to fit within a realtime buffer size. To
> > prevent the clicks ruining a performance, the fadeout time for voice
> > stealing needs to be quite a lot higher than the period size. Maybe
> around
> > 20ms to be on the safe side?
>
> Voice stealing is bound to the same audio fragment cycle. For one reason:
> if
> it was posponed to a subsequent audio fragment cycle then it would add
> (audible) latency to the newly spawned note/voice.
>
> So when voice stealing kicks in, it picks an old voice, "kills" the old
> voice,
> which means it ramps its volume down as fast as possible (as defined by
> CONFIG_EG_MIN_RELEASE_TIME), renders its audio, then the voice object is
> immediately conquered by the new note, which immediately starts to render
> its
> audio with the same voice (C++) object. So the trick is, when this is done
> in
> the same audio fragment, then you are using one voice (C++) object for
> actually two audible voices simultaniously, and hence it adds no latency
> for
> the new note/voice.
>
> Accordingly CONFIG_EG_MIN_RELEASE_TIME must not be bigger than your period
> size, otherwise you will see that mentioned warning message and you hear
> clicks. CONFIG_EG_MIN_RELEASE_TIME is a compile time option which you may
> lower to a certain degree. But obviously as soon as you make it soo small
> it
> results in audible clicks.
>
> > The maximum number of audio streams should never be reached, as voice
> > stealing should keep the number of audio streams to a sane level. But if
> > enough notes are played in too short a time to release within 20ms,
> maybe a
> > fadeout based on the period size should be used as a last resort?
>
> Streams and voices are dynamically assigned to each other. That's because
> the
> two are handled by two separate threads (disk thread and audio thread). So
> a
> voice requests a stream when it needs it and releases it when no longer
> needed. Due to the latency involved for handling this, the amount of max.
> streams should be higher than the amount of max. voices in practice.
>
> > I also notice that “Least buffer fill stream usage” in Qsampler exceeds
> 50%
> > fairly often, the linuxsampler process never takes up more than 10 CPU.
> > Maybe there's some internal limit on how much processing linuxsampler
> gets,
> > which could be removed?
>
> The performance bottle neck is usually the disk, not the CPU. But as long
> as
> you don't get audio dropouts then you can try to increase max. voices (and
> max. streams) to achieve a higher polyphony and reduce the potential
> requirement for voice stealing. You can easily play around with that i.e.
> from
> QSampler's settings dialog.
>
> 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
>
------------------------------------------------------------------------------
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
