Menu
▾
▴
linuxsampler-devel
|
From: Thomas H. <tho...@gm...> - 2018-01-24 00:03:08
Attachments:
Broberg03.MID
|
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 |
|
From: Thomas H. <tho...@gm...> - 2018-01-25 14:46:29
|
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 <tho...@gm...> 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 > |
|
From: Thomas H. <tho...@gm...> - 2018-02-08 16:01:01
|
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 <tho...@gm...> 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 <tho...@gm...> 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 >> > > |
|
From: Christian S. <sch...@li...> - 2018-02-08 18:47:24
|
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 |
|
From: Thomas H. <tho...@gm...> - 2018-02-09 19:36:30
|
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 < sch...@li...> 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 > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel > |
|
From: Christian S. <sch...@li...> - 2018-02-12 13:20:38
|
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 |
Thanks for helping keep SourceForge clean.
X