ExistentialAudio
Audio cracks/gaps on Ventura
Please Confirm
- [X] I have read the FAQ and Wiki where most common issues can be resolved
- [X] I have searched Discussions to see if the same question has already been asked
- [X] 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
- [X] 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
- Set audio output device to blackhole
- Set up a way to record or play the audio coming from blackhole
- Perform any of the "triggers" described above
Expected Behavior
No cracks.
Screenshots
My aggregate device:
Here is what I mean by crack/gap:
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?
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:
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: @.***>
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?
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.
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)
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: @.***>
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.
Actually, if the buffer length is small enough (tested with 5ms and 10ms), it also happens in Audacity.
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: @.***>
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: @.***>
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: @.***>
Thanks for the replies.
In Console, when the cracks happen, if I search blackhole I see this:
And if I search audio, I see several messages like the next one :
For setting the safety offset, do I need to do this? If not, how can I do it?
lol. I don’t even know what that means.
Anything when just searching for coreaudio?
Devin On Dec 29, 2024 at 3:26 AM -0800, Luís M. R. Guimarães @.***>, wrote:
Thanks for the replies. In Console, when the cracks happen, if I search blackhole I see this: image.png (view on web) And I see several messages like this one if I search audio: image.png (view on web) For setting the safety offset, do I need to do this? If not, how can I do it? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
Sorry I didn’t notice the 2nd screenshot.
So yes as suspected this is an audio overload issue. The solution is a larger buffer size. Or if you want the driver to handle this, increase the safety offset.
Devin On Dec 29, 2024 at 10:12 AM -0800, Devin Roth @.***>, wrote:
lol. I don’t even know what that means.
Anything when just searching for coreaudio?
Devin On Dec 29, 2024 at 3:26 AM -0800, Luís M. R. Guimarães @.***>, wrote:
Thanks for the replies. In Console, when the cracks happen, if I search blackhole I see this: image.png (view on web) And I see several messages like this one if I search audio: image.png (view on web) For setting the safety offset, do I need to do this? If not, how can I do it? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
Thanks Devin, but you also didn't notice my question hehe :) . Is this was the way to increase the safety offset?
That should work. Try it out and see what happens.
Devin On Dec 30, 2024 at 2:51 AM -0800, Luís M. R. Guimarães @.***>, wrote:
Thanks Devin, but you also didn't notice my question hehe :) . Is this was the way to increase the safety offset? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
@luismrguimaraes Did that help you overcome cracks.
I route the system audio to Blackhole 2ch and capture it and write to file to verify. There is also this crack sound in between.
cc @devinroth
Unfortunately I haven't manage to find the time to try it yet. I do plan on doing so eventually.
The issue seems worse when the RAM usage is higher. I hadn't restarted my mac in a while and was getting a lot of cracks, even with high buffer sizes (~2048 in Reaper) (and also with the locally built driver with a safety offset of 512). I've now restarted, and I'm able to get rid of the cracks with a buffer size of 512 in Reaper and 40ms of latency in Audacity (its default). I had actually noticed in the past, before using blackhole, that I heard similar cracks when the RAM usage was >14GB which seems like a Ventura or core audio bug.
After filling the RAM usage a bit more (now ~12GB/16GB), and building with a kLatency_Frame_Size of 32, I'm still recording cracks in Audacity when I set the latency to 5ms:
with these settings:
I'm confident I'm using the local blackhole and not the previously installed one because 1. I uninstalled the previous blackhole-2ch and 2. I'm seeing a different icon:
I'm not using the aggregate device in Audacity, but I am in Reaper, which allows me to hear the cracks in real time. Whenever I set similar latency values, the behaviour seems consistent between Reaper (with the aggregate device) and Audacity (without it).
I do still have the aggregate devices setup. Could the drift correction be interfering even though I'm not directly using the aggregate devices?
@luismrguimaraes this is quite helpful. If you can reproduce the issue than we can figure it out. My computers have 128gigs and 64gigs so I rarely max out the ram.
Are there any audio overload messages in Console when you're getting cracks?
So, just to note, I cannot recreate this issue with just the system audio, I'm only able to recreate the cracks when I use blackhole.
I do get overload messages in console, but only when using blackhole (crack "trigger" as at 22:24:59):
Without blackhole, I get this (crack "trigger" was at 22:26:39):
I pushed the RAM usage way up for these tests:
This might be the best behaviour given the situation. If there is in fact an overload, then we don't have much of a choice.
But having a larger safety offset should solve the problem. And it's not. Correct?
I've tested 512 before when RAM usage was ~14GB, and it didn't stop the cracks. I can try a really high safety offset and see if I get cracks even at high RAM usage.
Also, does it make sense that the overloads only happen when using the blackhole driver?
Can you reproduce on Sequoia?
Devin On Mar 4, 2025 at 3:03 PM -0800, Luís M. R. Guimarães @.***>, wrote:
I've tested 512 before when RAM usage was ~14GB, and it didn't stop the cracks. I can try a really high safety offset and see if I get cracks even at high RAM usage.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
luismrguimaraes left a comment (ExistentialAudio/BlackHole#824) I've tested 512 before when RAM usage was ~14GB, and it didn't stop the cracks. I can try a really high safety offset and see if I get cracks even at high RAM usage. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
Yes. Since there is no room for error BlackHole simply can’t wait for late audio.
The built-in devices have high buffer sizes and safely offsets to prevent this type of stuff.
Devin On Mar 4, 2025 at 3:04 PM -0800, Luís M. R. Guimarães @.***>, wrote:
Also, does it make sense that the overloads only happen when using the blackhole driver?
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
luismrguimaraes left a comment (ExistentialAudio/BlackHole#824) Also, does it make sense that the overloads only happen when using the blackhole driver? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
Can you reproduce on Sequoia?
Devin …
I can try tomorrow.
Yes. Since there is no room for error BlackHole simply can’t wait for late audio.
The built-in devices have high buffer sizes and safely offsets to prevent this type of stuff.
Devin …
Hmm, interesting. But that means that just increasing the safety offset would fix it. I'm now tempted to try higher buffer sizes than 512.
Yes in theory. Assuming this is a result of either the application taking too long or perhaps a macOS bug.
Classic “it’s not my fault”. But let’s find out.
Devin On Mar 5, 2025 at 11:21 AM -0800, Luís M. R. Guimarães @.***>, wrote:
Can you reproduce on Sequoia? Devin … I can try tomorrow. Yes. Since there is no room for error BlackHole simply can’t wait for late audio. The built-in devices have high buffer sizes and safely offsets to prevent this type of stuff. Devin … Hmm, interesting. But that means that just increasing the safety offset would fix it. I'm now tempted to try higher buffer sizes than 512. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.> luismrguimaraes left a comment (ExistentialAudio/BlackHole#824) Can you reproduce on Sequoia? Devin … I can try tomorrow. Yes. Since there is no room for error BlackHole simply can’t wait for late audio. The built-in devices have high buffer sizes and safely offsets to prevent this type of stuff. Devin … Hmm, interesting. But that means that just increasing the safety offset would fix it. I'm now tempted to try higher buffer sizes than 512. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.>