- everything in our collections is based on advanced IA !
- this site is managed by I.A. too
A few words
about crash reports
While this kind of direct support for developers turns out to be very handy, only very few users are actively supporting their developers with direct crash reports. ( This is just simply done by enabling Apples inbuilt crash reporting features on the devices. )
So most reports, we are seeing come from explizite crash reporting generated by Apples TestFlight. Most of these are completely anonymous, this means we cannot see who generated it, the e-mail for direct support must be provided explicitly by the users via TestFlight. So TestFlight and betas are important for developers.
Here is a screenshot, that demonstrates how this works :
In the screenshot above you can see, all important and required information for a developer is there and you finally are even able to exactly identify ( and fix ) the issue or just work around it.
This is such a crash report, generated by TestFlight from anonymous usage, where you can see the exact line of code in Apples Xcode compiler environment with the loaded project.
The report was generated on a device, which obviously was not updated for a longer time. It (exemplary) was an IPad Air (3rd Gen.) with iOS 16.6.1 in this case. Most crashes we see, b.t.w. are coming from outdated devices and operating system versions by the way.
( This is especially true with the iOS music community, sometimes using unacceptable old devices and OSs – then blaming developers for their crashes! Unfortunately there is no real support from Apple to exclude some sort of devices from distribution. Merely only supporting latest OS version would help here – but potentially reduct the sales to virtually zero then. If I was Apple, I would actually check which OS version the users have installed, prior considering them being eligible for a refund. And refunding users without letting the developer know at all, what the exact reason for the refund was, is generally idiotic like hell. )
But the really interesting part here is the crash reason. The crash was obviously caused by an artificial Apple exception (most crashes on Apple’s devices are of that kind by the way). AVAudioEngine is particularly extremely prone to such artificially generated crashes, instead just skipping one step silently or just providing a useful error message to the user, for instance…
It remains still a miracle, why it crashes on this particular user device, as we test on at least 3 different latest Apple devices on all platforms ( iOS, iPadOS, macOS – everything Apple Silicon with actual iOS versions ), but we are able to work around in this special case.
In this case we will remove that idiotic Apple AUPeakLimiter, a system component, which obviously is not able to connect to the native hardware sample rate (!) of the device and thus is creating a crash and blaming the 3rd party developers for that. ^^
So the crash is NOT caused by JAX Supersonic AudioUnit, but by the host app, using Apples inconsequently designed audio system components.
The ‘issue’ will be fixed with next update, as it also does not even affect the operation of the JAX Supersonic AudioUnit.
Addendum: 90 percent of crash reports we see, are caused inside the Apple audio frameworks and we merely do apply workarounds to that then, if even possible.
A few words
for why we dropped active Intel device support
The crash report example above demonstrates implicitly an important consideration to us. Most Apple devices, where our AudioUnits are used, are Apple Silicon devices.
A year ago we still used Apples latest Intel MacBook Pro 16 with external monitors for app development. This machine was quite busy when compiling our projects, some of them required extremely long compile times and that device was running hot all days long, endlessly generating ventilation noise.
Now, for some time, we use Apples latest MacBook Pros with M2 Pro / M3 Pro Processors and this is much much faster and also cooler ( in the word’s true sense here ).
But the real reason why we now switched to Apple Silicon completely is, that these devices are running the same chip family as the destination devices.
The Intel machine was generating code for the Silicon devices, but in reality we could not be sure, whether it really would would work on the user’s destination devices as to expect and many issues just could be translation issues from the compiler, even in such sensitive areas as the audio processing area.
But on the counter side, we are now not able anymore to consequently support old Intel architectures actively. The old MacBook Pro 16 does not get switched on lately very often …
Well, and the current Apple compilers, running natively on the M1/2/3 chips are still able to produce universal binaries for the Intel family of processors on the Mac. But we cannot be sure about the results and so we will drop and tear down Intel support for our releases and updates.