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
