Hi all,
Please let me know if there's a better place to be sending these messages...
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?
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?
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?
I'll try to make some example recordings of when errors occur soon, to make
this a bit clearer. I'm also happy to sponsor these issues if fixes are
manageable. My setup is glitchy at the moment, but apart from that it
sounds amazing.
(~: Tom
On 25 January 2018 at 14:46, Thomas Howe <tho7maspeng...@gmail.com> wrote:
> Update:
>
>
> I have found that setting the maximum number of voices to 1 seems to
> eradicate the xruns completely! I hope this will be true for some higher
> numbers of voices too. It was previously set to something like 60.
>
>
> The non-xrun clicks are still present, every time I play a note before
> another has died (including release time I think). I also get this error
> message in Qsampler:
>
> EngineBase: WARNING, CONFIG_EG_MIN_RELEASE_TIME too big for current audio
> fragment size & sampling rate! May lead to click sounds if voice stealing
> chimes in!
>
>
> Which suggests my period size of 64 samples at 96kHz (0.67ms) is too low.
> So I will look into decreasing CONFIG_EG_MIN_RELEASE_TIME and report back
> when I find out how to. Any hints would be appreciated.
>
>
>
> I think, if this works, then to stress test my setup properly I would need
> some way to verify that the non-xrun clicks are really gone. Like some kind
> of LinuxSampler click counter. Is there a way to do this?
>
>
> On a side note, is there a way to run LinuxSampler in non-realtime mode,
> so that very polyphonic pieces or possibly even Black MIDI could be
> rendered?
>
>
>
> Please let me know if there's a better place to post this.
>
>
>
> (~: Tom
>
>
> On 24 January 2018 at 00:03, Thomas Howe <tho7maspeng...@gmail.com> wrote:
>
>> Hi all, me again...
>>
>> Sometimes LinuxSampler's audio seems to glitch and cause xruns. Xruns
>> aren't registered by patchage and xrun-logger each time.
>>
>> Is this a normal issue? I think it might be related to polyphony (it
>> tends to occur when the sustain pedal is used in fast passages).
>>
>> I would imagine that pitch-shifting a lot of note samples at the same
>> time and then playing them all would be a very intensive task and likely to
>> cause audio glitches, but the processors don't max out or anything.
>>
>> Attached is a MIDI file (Liszt's 2nd Sonata in B Minor) which when played
>> with the SalamanderGrandPianoV3Retuned instrument, gives me a lot of audio
>> glitches.
>>
>> Also I'm using JACK2.
>>
>> Any advice still appreciated (:
>>
>> Tom
>>
>
>
------------------------------------------------------------------------------
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
