 |
Given that the issue is not present when rendering to streamed audio, what you are experiencing must be a buffer underrun in audio playback. The Chorus effect is pretty much 25 years old, so it's unlikely in itself to cause so much CPU load that you wouldn't be able to use it in realtime. I guess in theory it's possible that you hit a set of parameters that maybe result in denormalized floats, but I don't see any issue here with the parameters chosen in your demonstration video. Can you provide the original module just so that we can be sure we are testing the same thing? Please also check the audio device settings in OpenMPT, what latency and period values have you chosen there, and does increasing them help? |
 |
CPU load is by no means what's causing this, playback routine eats maybe 15% CPU tops on an i5-8500 |
|
|
15% on an i5-8500 is one full core - OpenMPT's rendering is not multi-threaded so if for whatever reason the rendering occupies a full core on that machine (to be clear: it shouldn't), that could explain audio dropouts. |
|
|
No no I meant 15 percent of a core. Task manager graphs it about 15-20 percent extra usage on the core the Windows scheduler assigns it (usually core 1 out of six). Otherwise I'd have been here asking a completely differeny question � |
|
|
Either way - what can be heard in the video are clear dropout artifacts, which is confirmed by the fact that it doesn't happen during export. Since effects are always-on, and you have four effects in that module, the next step would be to bypass the two reverb plugins and see if it makes any difference. I would suspect the I3DL2Reverb could be real culprit here, since it doesn't have any code to prevent denormals (the WavesReverb does). Intel CPUs in particular may struggle with denormals from what I remember, which would explain why I don't see the problem even in slow debug builds (I'm on AMD). |
|
|
Bypassing the reverb plugins does not help. As a double check, I also tested the module on an i5-2520M, an i7-1165G7, an i5-8250U, and a few other cpus. Multiple pairs of headphones, even remote desktop produces the same effect. Drops at the extremes of the chorus phase. I also ruled out the "extremes" of the chorus phase being the click, as setting the frequency of the phase high or low does not influence the pop. Only Depth makes any difference, not counting Wet/Dry as it just mixes between the config and no chorus at all. I don't think anyone had really noticed before. What in the It's the citradvance SRL DS(I)sion menu X++II+++++++ oader menu ++X++ is happening here |
|
|
I tried on two i7s today and also was not able to reproduce the issue there, so most likely that's unrelated. Let's try to reduce the repro case down to something with fewer variables. Please try reproducing this with a newly-created module, just containing one Chorus plugin instance, and only one sample / instrument. Preferably something simple like a sine wave. Does it also happen there? And does it only happen in the instrument tab, or also when the notes are triggered in the pattern editor? |
|
|
Oh shit it isn't the depth slider either I just forgot to ever tamper with the Wet/Dry. So just having the chorus effect applied without actually having any depth still gives a click. Default settings also provides the click. Here's a 1 instrument sinewave-y with ONLY a chorus effect. Untouched settings on that effect. Click happens in all instances of playback within the program. |
|
|
Side-side note: Also tested this on a few devices, same ordeal |
|
|
I can reproduce the issue now, but only after changing the output rate to 192 kHz. It is also reproducible when exporting the file in that case, which is what threw me completely off in the initial analysis. Were you perhaps exporting to a format that doesn't allow such a high sample rate (Ogg / Opus / MP3)? Anyway, the problem is also present in Microsoft's original DMO implementation. Keep in mind that these algorithms were designed 25+ years ago and nobody would have probably expected that they'd be run at such a high sample rate. In theory the effect should be able to adapt to any sample rate, so we'll need to figure out where this adaption fails, and if it can be fixed in a way that wouldn't make lower sample rates change their behaviour, |
|
|
Oh shit I've been exporting in 96khz FLAC and had MPT set to 192khz on every testing device. All my sound hardware supports it so I was like "Why not, it sounds better and it's the hardware native sample rate." But my bluetooth headphones have LDAC so for personal listening thru my phone during commute I had chosen 96khz Flac 8-bit vol. depth as 96 kHz is LDAC highest sample rate and 8 bit because I like the soft hiss and it yields a sub 15-meg file size on average. NOW this makes sense... I don't think you have the time to dig into it very much further but for the time being I'll change my hardware sampling rate to 176khz or something that works. The difference is almost net zero anyways :) |
|
|
I think at 176kHz I also noticed the issue. From the supported sample rates, 96kHz is the highest that doesn't expose the problem. It's definitely a valid bug report so I will look into it, but no promise if there can be an immediate fix. |
|
|
No biggie. Thanks for the help ♡ |
|
|
Initial observation: Regardless of Chorus settings (depth etc. does not matter), the click happens every 425984 samples (about 2.2 seconds) at 192 kHz, at 176 kHz it happens every 306176 samples (about 1.74 seconds). This is strange because the delay line is always 3.84s long. So especially at a depth of 0, where the signal does not move forwards and backwards a lot (relative to the source signal), there should always be plenty of room in the buffer to not run into the end of the buffer. |
|
|
Duh. Multiplying that almost 4-second buffer length with 4096 for the fractional precision bits yields a negative 32-bit number. That's where it's coming from... that should be an easy fix. |
|
|
Fixed in r20302. |
- Anonymous
