HALC_ProxyIOContext::IOWorkLoop: skipping cycle due to overload

General JUCE discussion
1

Anyone else seeing this at higher sample rates since upgrading to macOS Sonoma 14.4.1 ?

It causes distortion during playback of the Standalone VI I’m working on at 96kHz.

I have an M3 Max MacBook Pro with 64GB of RAM

So far only appears to happen in Debug, but this is new behavior since upgrading from 14.4 (which is necessary for PACE auval compatibility).

Rail

4 Likes
2

+1, I’m getting this same error Sonoma 14, M1 Macbook Air.

Context:
I’m making some edits to the Vital synthesizer (GitHub - mtytel/vital: Spectral warping wavetable synth).
It works well when playing <4 notes simultaneously, but 4 or more sustained notes causes the HALC_ProxyIOContext::IOWorkLoop: skipping cycle due to overload error. The audio begins stuttering and clipping, and it affects multiple apps not just the vital build.
Happens in both Debug and Release, and at any sample rate and buffer size.

Any ideas?

2 Likes
3

I have had unusable audio on debug builds since I started using a SIMD library (MIPP) but I had already read posts and was expecting this.

I am not sure when the HALC_Prox… error messages started, but sometime in the last few weeks. This happens at all sample rates and with all my audio devices on debug builds.

Sonoma 14.3 8GB M2 MacBook Pro

4

+1 here, I’m certainly getting this today in debug, not sure exactly when it started. M1 MacBook Air, Sonoma 14.1.1

Really no ideas but chiming in case any thoughts come up.

1 Like
5

is there anyway to turn this warning off does anyone know?

1 Like
6

Christ, this is driving me crazy.

1 Like
7

Bumping

Are these HALC_ProxyIOContext “skipping cycle due to overload” messages in Xcode’s console related to Juce?

Or are all Apple developers bombarded with these unhelpful messages?

Google does not come up with Apple documentation results

1 Like
8

still driving me crazy

1 Like
9

Claude.ai “Disabling “skipping cycle due to overload” warnings in Xcode” options:

https://claude.ai/share/1b2ced3b-bec8-47bd-a15b-f12dc6bb1c1d

Rail

1 Like
10

the link doesn’t work.
could you please post the reply so that myself and others don’t have to sign up? thanks!

11

I’d recommend you create a Claude.ai account anyway, but here’s the pertinent info:

Based on my research, here are several ways to disable or filter out the “HALC_ProxyIOContext::IOWorkLoop: skipping cycle due to overload” warnings in Xcode:

Option 1: Filter the Console Output

In Xcode 15 and later, you can take advantage of improved debugging console features to filter logs by type, category, or message content. Nil Coalescing

To filter out these specific warnings:

  1. In Xcode, open the debug console (Cmd+Shift+Y if it’s not already visible)
  2. Click on the filter icon in the console
  3. Add a filter that excludes messages containing “HALC_ProxyIOContext”

Option 2: Use OS_LOG Subsystem Filtering

Xcode 15’s console supports filtering based on log levels, and you can hide specific subsystems. SwiftLee

The HALC warnings are coming from the AudioHAL_Client subsystem. You can:

  1. In the console, click the “Action” menu (gear icon)
  2. Go to “Include Info Messages” and “Include Debug Messages”
  3. Then add a custom filter to exclude the specific subsystem

Option 3: Use an Environment Variable

You can add an environment variable to your scheme:

  1. In Xcode, click on your scheme (next to the run/stop buttons)
  2. Select “Edit Scheme…”
  3. Go to the “Run” section, then “Arguments”
  4. Under “Environment Variables”, add:
  • Name: OS_ACTIVITY_MODE
  • Value: disable

This will disable many system logs, including the HALC warnings. Note that this will also disable other potentially useful logs.

Option 4: Use a Custom Logging Environment

You can reduce verbosity of logs when debugging by configuring specific subsystems. Apple

Create a custom .plist configuration file that specifically silences the AudioHAL logs by adding this environment variable to your scheme:

  • Name: OS_LOG_FILTER
  • Value: AudioHAL_Client:off

Additional Context

These warnings typically appear when there are audio processing overloads, which can happen during high CPU usage or when running audio code in debug mode. The warnings are often seen in audio applications, especially at higher sample rates, and can be related to system audio processing struggling to keep up. JUCETonymacx86

While filtering the warnings will make your console cleaner, note that they might be indicating a real performance issue in your app, especially if you’re doing audio processing.

12

I did follow up:

Based on my research, I can provide several options to persistently disable those HALC_ProxyIOContext warnings across your Projucer projects:

Option 1: Create a Global Environment Setting with environment.plist

You can create a system-wide environment variable that will affect all applications (including Xcode) by creating an environment.plist file in your user directory. Stack Overflow

  1. Create the file: ~/.MacOSX/environment.plist (you may need to create the .MacOSX directory)
  2. Add this content to the file:

xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>OS_LOG_FILTER</key>
    <string>AudioHAL_Client:off</string>
</dict>
</plist>
  1. Log out and log back in to apply the changes

This will apply the environment variable to all applications launched by your user, including Xcode, and should persist between Projucer export operations.

Option 2: Use an xcconfig File with Projucer

While Projucer doesn’t directly support custom xcconfig files, you can include them in your project to maintain consistent settings across rebuilds. JUCE

  1. Create a file named LogFilter.xcconfig in your project directory with this content:
OTHER_CFLAGS = $(inherited) -DOS_LOG_FILTER="AudioHAL_Client:off"
  1. In Projucer, under “Extra Compiler Flags” add:
#include "LogFilter.xcconfig"
  1. Save the Projucer project and export

This approach uses preprocessor definitions to achieve a similar effect.

Option 3: Post-Export Script

Since adding environment variables via Projucer is a requested but not yet implemented feature, you can use a post-export script that modifies the scheme files. JUCE

Create a shell script that you run after exporting from Projucer:

bash

#!/bin/bash
SCHEME_PATH="YourProject.xcodeproj/xcshareddata/xcschemes/YourProject.xcscheme"

# Create the directory if it doesn't exist
mkdir -p $(dirname "$SCHEME_PATH")

# Check if the scheme exists
if [ -f "$SCHEME_PATH" ]; then
    # If it exists, add the environment variable if not already present
    if ! grep -q "OS_LOG_FILTER" "$SCHEME_PATH"; then
        sed -i '' '/<\/BuildableReference>/a\
         <EnvironmentVariables>\
            <EnvironmentVariable\
               key="OS_LOG_FILTER"\
               value="AudioHAL_Client:off"\
               isEnabled="YES">\
            </EnvironmentVariable>\
         </EnvironmentVariables>' "$SCHEME_PATH"
    fi
fi

Run this script after each Projucer export.

Option 4: Modify Projucer Source Code (Advanced)

If you’re comfortable with C++ and building Projucer from source, you could modify the Xcode exporter in the JUCE source to automatically include your environment variables. GitHub

The relevant file is jucer_ProjectExport_Xcode.h in the JUCE repository. You would need to modify the scheme generation code to include your environment variable.

Recommendation

The environment.plist approach (Option 1) is likely the simplest and most reliable solution, as it applies system-wide and doesn’t require modifying your Projucer projects. It will work even if you create new projects or import existing ones.