Audio cracks/gaps on Ventura

[luismrguimaraes]

Please Confirm

• I have read the FAQ and Wiki where most common issues can be resolved
• I have searched Discussions to see if the same question has already been asked
• This is a bug and not a question about audio routing or configuration, which should be posted in Discussions

macOS Version

macOS 13 Ventura

BlackHole Build(s) Affected

• 2 channel
• 16 channel
• 64 channel
• other/custom build

Describe the bug

I keep getting cracks/gaps while using the computer normally. I've found three specific instances where I can easily reproduce this. I use an app called Simplenote and whenever a note is saved, there is a crack/gap in the audio that is playing. Also, when using the cmd+F search feature in Firefox, I also get cracks whenever my prompt is not found. Finally, when screenshotting with cmd+shift+4 it also happens.
I'm routing the audio like this: Blackhole -> DSP software -> Headphones.

So far, I've tested playback in Reaper and the JUCE AudioPluginHost and also tested recording in Audacity. The cracks don't happen when I send the audio directly to the headphones, that is why I believe the issue is with blackhole, but I'm available to do further testing.

Reproduction Steps

1. Set audio output device to blackhole
2. Set up a way to record or play the audio coming from blackhole
3. Perform any of the "triggers" described above

Expected Behavior

No cracks.

Screenshots

My aggregate device:

Here is what I mean by crack/gap:

[orchetect]

Are your system sound effects assigned to the aggregate device as well as system audio output? If so, does it still happen when you reassign the sound effects to a different device completely unrelated to the aggregate?

[luismrguimaraes]

I'm unsure what you mean by "system sound effects".

For example, in Reaper I use this (with the aggregate device I shared above)

In the AudioPluginHost, this is the setting:

In Audacity:

Then, this is what each device settings look like:

I'm not using Multi-Output devices, but I do have two created the same way I have two aggregate devices with blackhole:

[devinroth]

Let me be more specific. There are known issues with drift correction with Apple’s multi-outputs/aggregates. I want you to be able to reproduce this issue without using them. What is outputting audio to BlackHole? Devin

…

On Dec 26, 2024 at 4:48 AM -0800, Luís M. R. Guimarães ***@***.***>, wrote: I'm unsure what you mean by "system sound effects". For example, in Reaper I use this (with the aggregate device I shared above) image.png (view on web) In the AudioPluginHost, this is the setting: image.png (view on web) In Audacity: image.png (view on web) Then, this is what each device settings look like: image.png (view on web) image.png (view on web) I'm not using Multi-Output devices, but I do have two created the same way I have two aggregate devices with blackhole: image.png (view on web) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[luismrguimaraes]

I'm setting the device output to BlackHole

and have now tried recording with Reaper with its settings like this:

but am still getting the cracks/gaps

Should I also try deleting the aggregate devices and multi-output that include BlackHole?

[orchetect]

A sample buffer ("block size") of 64 is really low and is a frequent cause of dropouts.

Try setting it to 128 or even 256 and see if the dropouts still occur. It's at least something to rule out.

[luismrguimaraes]

Still happening with 256. I've tested with audio from Spotify, Youtube and VLC.

(tested with the same setup as above but a different block size)

[devinroth]

Okay. One more thing before I attempt to reproduce. Restart your computer and try again. Devin

…

On Dec 26, 2024 at 11:27 AM -0800, Luís M. R. Guimarães ***@***.***>, wrote: Still happening with 256. I've tested with audio from Spotify, Youtube and VLC. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[luismrguimaraes]

After restarting, it is not happening in Audacity. It still happens in Reaper (with the aggregate device) and in the AudioPluginHost (with each device selected separately for input and output) but is less frequent the more I increase the buffer size. 1024 samples seems to be the best value with very rare crack/gap occurrences.

I had actually not tried 512 or 1024 buffer sizes before, but I'm not sure if this should be considered a solution to the problem. I'm noticing that what I'm doing to trigger the cracks causes small CPU spikes, but because they are so small (from ~4% to ~8%) I wouldn't expect them to interfere with the audio because they are not high priority (from a user perspective) but they are likely getting priority over BlackHole.

[luismrguimaraes]

Actually, if the buffer length is small enough (tested with 5ms and 10ms), it also happens in Audacity.

[devinroth]

Are you getting any overload errors in console? A little background here, BlackHole does not add any additional latency and relies on the buffers of the applications to arrive at the required time so there’s enough internal processing time to do any copy operations. If either application is writing the audio buffer late or if the callback is earlier there will be a click. This can be solved internally by creating a safety offset inside the driver but that is essentially the same as increasing the buffer size of the applications. The click is clearly being caused by an OS interruption of the real-time audio through. Something that should never happen but I’ve found that many audio developers are “lazy” and instead of ensuring 100% safe operations they cut corners. The correct way to do this is to ensure an application is never interrupted by OS but some libraries are poorly written and are integrated all over the place. That means it ends up being “BlackHole’s fault” and we have to compensate for the poor decisions of other developers. Adding a small safety offset in BlackHole should solve the problem. But is that really the solution? Devin

…

On Dec 26, 2024 at 2:48 PM -0800, Luís M. R. Guimarães ***@***.***>, wrote: Actually, if the buffer length is small enough (tested with 5ms and 10ms), it also happens in Audacity. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[devinroth]

I’m getting all philosophical about the correct way to do things but users be like “I don’t care, I just want it to work”. Devin

…

On Dec 27, 2024 at 10:57 AM -0800, Devin Roth ***@***.***>, wrote: Are you getting any overload errors in console? A little background here, BlackHole does not add any additional latency and relies on the buffers of the applications to arrive at the required time so there’s enough internal processing time to do any copy operations. If either application is writing the audio buffer late or if the callback is earlier there will be a click. This can be solved internally by creating a safety offset inside the driver but that is essentially the same as increasing the buffer size of the applications. The click is clearly being caused by an OS interruption of the real-time audio through. Something that should never happen but I’ve found that many audio developers are “lazy” and instead of ensuring 100% safe operations they cut corners. The correct way to do this is to ensure an application is never interrupted by OS but some libraries are poorly written and are integrated all over the place. That means it ends up being “BlackHole’s fault” and we have to compensate for the poor decisions of other developers. Adding a small safety offset in BlackHole should solve the problem. But is that really the solution? Devin On Dec 26, 2024 at 2:48 PM -0800, Luís M. R. Guimarães ***@***.***>, wrote: > Actually, if the buffer length is small enough (tested with 5ms and 10ms), it also happens in Audacity. > — > Reply to this email directly, view it on GitHub, or unsubscribe. > You are receiving this because you commented.Message ID: ***@***.***>

[devinroth]

Test this out, Set the safety offset to something like 32 and see what happens. Devin

…

On Dec 27, 2024 at 11:17 AM -0800, Devin Roth ***@***.***>, wrote: I’m getting all philosophical about the correct way to do things but users be like “I don’t care, I just want it to work”. Devin On Dec 27, 2024 at 10:57 AM -0800, Devin Roth ***@***.***>, wrote: > Are you getting any overload errors in console? > > A little background here, BlackHole does not add any additional latency and relies on the buffers of the applications to arrive at the required time so there’s enough internal processing time to do any copy operations. If either application is writing the audio buffer late or if the callback is earlier there will be a click. This can be solved internally by creating a safety offset inside the driver but that is essentially the same as increasing the buffer size of the applications. > > The click is clearly being caused by an OS interruption of the real-time audio through. Something that should never happen but I’ve found that many audio developers are “lazy” and instead of ensuring 100% safe operations they cut corners. The correct way to do this is to ensure an application is never interrupted by OS but some libraries are poorly written and are integrated all over the place. That means it ends up being “BlackHole’s fault” and we have to compensate for the poor decisions of other developers. > > Adding a small safety offset in BlackHole should solve the problem. But is that really the solution? > > Devin > On Dec 26, 2024 at 2:48 PM -0800, Luís M. R. Guimarães ***@***.***>, wrote: > > Actually, if the buffer length is small enough (tested with 5ms and 10ms), it also happens in Audacity. > > — > > Reply to this email directly, view it on GitHub, or unsubscribe. > > You are receiving this because you commented.Message ID: ***@***.***>