Audio glitches in Chorus and Flanger mode on record-enabled tracks in Logic

[anthonyalfimov]

DAW	Bug
Logic 10.6.1 Intel	[ + ]
Reaper 6.23 ARM beta	[ - ]
Reaper 6.23 Intel	[ - ]
Logic 10.6.1 ARM	[ + ]
Logic 10.5.1 Intel	[ + ]

---

Discontinuities in the audio output of the plugin in Chorus and Flanger when a track in Logic is connected to a physical input. The audio glitches only appear when the track is armed for recording and/or when input monitoring is enabled on the track. Glitches are independent of the plugin gain settings.

Glitches are not present in delay mode.

Glitches get worse with smaller audio buffer size, while increasing it can solve the problem.

---

Solution:

With Logic's "Process Buffer Range" setting (Audio -> Devices), it uses a larger block size when no physical inputs are being monitored. This larger block size is the one that is supplied to prepareToPlay(). When a physical input is being monitored, Logic reduces the block size to the one defined by the "I/O Buffer Size" setting. The smaller block size is only supplied as the numSamplesToRender to the process() function, without prepareToPlay() being called.

Therefore, assuming that the block size is equal to the one passed to prepareToPlay() can lead to problems. prepareToPlay() should be only used to set the maximum block size.

[anthonyalfimov]

Hypotheses

Things to explain: source of discontinuities; connection to the audio buffer size; connection to delay time modulation; why the problem is present on some systems, but not on others.

1. ~CPU cannot finish the instructions in time - actual performance issue. As far as I know, in this case one of the CPU core load meters in Logic should be maxing out. Might be possible due to differences in instruction optimisation on different CPUs. Doesn't seem very likely to me right now. Should be easily testable by observing the CPU load meters.~

2. ~Discontinuities due to processor thread being locked / other threading issues. As I understand, different systems/CPUs can handle threading differently. It might be that certain threading issues don't arise on my machines, but exist in the code. It's unlikely that it's connected to atomics, because then everything would produce glitches, not just the modulation. Is there something unique in terms of threading to the LFO module?~

3. Discontinuities in the modulation buffer. Modulation in the plugin is directly connected to the block size: a modulation buffer is allocated to have the same size as the block size. Maybe the LFO or Delay module are relying on some undefined behaviour that can differ between systems? Not handling or incorrectly handling some system-dependent behaviour?

4. ✅ Some unaccounted difference in testing setup is causing the glitch, not a difference in the system / hardware. The reason why I couldn't reproduce the problem is that I wasn't reproducing the testing conditions exactly. This unaccounted factor could be not properly handled by the plugin, which causes the discontinuities in audio output. For example,~ the plugin is forced into mono->stereo channel configuration (mono audio file on a stereo track?)~, or enabled recording + input monitoring on the track?

[anthonyalfimov]

No luck reproducing this so far. My old iMac runs a universal binary compiled on the M1 with no issues; no glitches even at 32 sample buffer size.

[anthonyalfimov]

Things to test

• [x] What is the state of Logic CPU meters when the glitch happens?

  The CPU load becomes slightly higher when input monitoring is enabled and the glitch is introduced, but it's still nowhere near the max. Visually, I'd say it's around 5%, no more.

• [x] Does the "Width" knob affect the glitch in Chorus / Flanger mode? Is the glitch still present at 0 "Width"?

  No, the glitch is present at all "Width" settings.

• [x] Does the "Width" knob affect the glitch in the Delay mode? Does the glitch appear at high "Width" setting?

  Inconclusive, doesn't appear so. However, modulation in Delay mode is fixed to a very slow rate, and the glitches seem to be linked to a higher rate modulation.

• [x] Is the glitch still present when the plugin UI is closed?

  Yes, UI being closed does not affect the glitch and it is still present.

• [x] Does the glitch appear when putting a mono audio file on a stereo track (e.g., creating a mono track with a mono audio file and later converting it to stereo)?

  No issues when processing a mono audio file on a stereo track.

• [x] Does the glitch appear when the track is connected to a physical input with input monitoring and recording enabled? (Check with software monitoring on and off; low latency mode on and off).

  Enabling input monitoring or recording on a track connected to physical input produces the glitch. Software monitoring setting and low latency mode setting do not appear to affect the glitch.

[anthonyalfimov]

Hypothesis 4 confirmed: glitches are caused by arming a track for recording or enabling input monitoring (track must be connected to a physical input).

I have now successfully reproduced the bug.

H4, however, does not explain the actual cause of the glitches. Based on the tests above, it does not appear that this is a performance or threading issues.

[anthonyalfimov]

Hypotheses

Things to explain: glitches are caused by arming a track for recording or enabling input monitoring (track must be connected to a physical input); the glitches are linked to the delay time modulation; higher modulation rate and depth produces more glitches and vice versa; glitches disappear at modulation depth = 0; glitches are affected by the buffer size: smaller buffer size produces more glitches, larger - less.

4.1. Logic uses a smaller buffer size than defined by the settings when input monitoring is enabled. In this case, prepareToPlay() might not be called. LFO module cannot handle resizing of the buffer without prepareToPlay() being called by the host.

[anthonyalfimov]

With Logic's "Process Buffer Range" setting (Audio -> Devices), it uses a larger block size when no physical inputs are being monitored. This larger block size is the one that is supplied to prepareToPlay(). When a physical input is being monitored, Logic reduces the block size to the one defined by the "I/O Buffer Size" setting. The smaller block size is only supplied as the numSamplesToRender to the process() function, without prepareToPlay() being called.

Therefore, assuming that the block size is equal to the one passed to prepareToPlay() can lead to problems. prepareToPlay() should be only used to set the maximum block size.