Jassert (bufferSize == (int) numFrames) being hit on iOS 18.4 simulator

MacOSX and iOS
1

Hey there

I was playing around with iOS simulators and JUCE 8.0.7 (Master) and immediately hit this:

        // If you hit this assertion please contact the JUCE team and let us
        // know the iOS version/device and audio device that you're using
        jassert (bufferSize == (int) numFrames);

aka
JUCE Assertion failure in juce_Audio_ios.cpp:1076

As mentioned this was with iOS18.5 simulator using iPhone 13 and 16 simulated devices.

The issue does not present with JUCE 8.0.6 (Master).

Hope this helps - let me know if there’s anything I can do at my end.

Cheers, J

CoreAudio crashing after initialising devices with different buffer sizes
2

Thanks! is this happening while changing buffer size? what are the values of bufferSize and numFrames? does it get continuously hit or does it correct itself eventually?

1 Like
3

Hey @anthony-nicholls thanks for the super quick reply.

First 8.0.6 Master:
Taking a look a this again, although the iOS simulator works with JUCE 8.0.6 Master this looks concerning

AudioHardware-mac-imp.cpp:2706   AudioDeviceStop: no device with given ID
            HALSystem.cpp:2170   AudioObjectPropertiesChanged: no such object

further more there is a stream of this

Input data proc returned inconsistent 1 packets for 1880 bytes; at 4 bytes per packet, that is actually 470 packets

I dont get that on physical devices – I’m wondering if thats a clue.

Next 8.0.7 Master:
Moving back to JUCE 8.0.7 Master I stuck a DBG line ahead of the assertion and got this, and only once on start up. The crash condition was immediate.
bufferSize: 128 vs numFrames: 512

Finally removing the jassert in 8.0.7 Master
Commenting out jassert (bufferSize == (int) numFrames); line lead to a continuous stream of my DBG suggesting that yes it does continuously get hit, and does not self-correct.

I hope this helps. Please let me know if I can doing anything else at my end. For now it’s back to 8.0.6 for me! :slight_smile:

Best wishes
Jeff

4

Thanks for reporting this issue.

We’ve pushed a few changes to the develop branch. The most significant change is that the CallbackMaxSizeEnforcer has moved from the StandalonePluginWrapper to the AudioDeviceManager:

This means that every audio device that is accessed through the AudioDeviceManager should have the max buffer size properly enforced. This includes the iOS audio device.

I hope that this change will resolve the issues you’ve been seeing. Please let us know if you’re still experiencing problems after updating.

1 Like