macOS v Windows 10

[BKDad]

This may have been discussed previously, but I was unable to find it in a search. (If I missed it, I'm fine with somebody calling me out here.)

I use an Intel iMac for REW and other engineering tasks. Normally, I use Windows 10 running in Boot Camp for this.

Today I compared some simple test results using REW in both macOS Sonoma and Windows 10. Same hardware - the cables weren't even touched between tests. I used the same settings for REW throughout, at least where applicable. In Windows 10, I used Java EXCL WASAPI drivers for both the DAC (Topping E50) and ADC (Cosmos ADC).

As these show, the results are pretty similar. There's some extra low level spurs with Win10. But, the big difference is the 2nd harmonic measurement.

As a sanity check - which I always need - I also ran the same test using Multitone Analyzer. Very similar results to REW in Win10, maybe without some of the low level spurs.

Why could this be?

Now, this is really not a big deal. Kind of one of these annoying details that's kind of curious.

Is the macOS version of REW running in Exclusive Access mode for the devices? Could one of these operating systems be resampling somewhere?

Thanks!

 

[John Mulcahy]

Under macOS the device runs at the rate configured for it in Audio Midi Setup and if REW is asking for something different the OS will resample.

 

[BKDad]

Thanks for the fast response.

Changing the sample rate in Audio Midi Setup to match what's set in REW made the Windows and macOS results to be almost identical. The Win10 display has some extra "stuff" in it that doesn't show on either the macOS version of REW or with Multitone Analyzer, but it's low level.

I'm pretty sure that it's programmatically possible to obtain exclusive access for an audio device connected to macOS and also possible to change the data rates from within the program. I have a playback application from this fellow: SBoooth slash SFBAudioEngine on Github (I can't post links) that does just that. I know there are others as well. You probably have a good reason why you don't do that, though.

Again, thanks very much.

 

[John Mulcahy]

Java applications are abstracted from the hardware and cannot directly control it. On Windows the WASAPI exclusive and ASIO drivers use 3rd party Java libraries that run native code to enable that access. I don't have an equivalent for macOS.

 

[BKDad]

I certainly am not a software guy, so I can't comment. But, I do think that he sends commands to the operating system to make the changes. When the sample rate for a track changes from the previously played track, I can see the sample rate getting changed in Audio Midi Setup.

I think that his app may talk to the Audio Midi Setup app and not the hardware, but I'm not sure how. That may not be possible with Java.

 

[sam_adams]

I'm pretty sure that it's programmatically possible to obtain exclusive access for an audio device connected to macOS and also possible to change the data rates from within the program.

Just about everything you would need to know about how macOS handles audio—including CoreAudio's exclusive mode (known as 'hog' mode on macOS)—is described below:

Secrets of Audiophile Playback on macOS

I never understood why some audiophile players exhibit professionalism via unnecessary playback settings. This is not honest in Dieter…

medium.com

The author of the article is also the person who created the Tonal app for macOS. It is an interesting player app, quite unlike others you may have used.

 

[phofman]

I'm pretty sure that it's programmatically possible to obtain exclusive access for an audio device connected to macOS and also possible to change the data rates from within the program. I have a playback application from this fellow: SBoooth slash SFBAudioEngine on Github (I can't post links) that does just that.

That's exactly the case. The OSX audio API must be used to set the hog mode - e.g. methods https://github.com/sbooth/SFBAudioE...29e845493a/Device/AudioDevice.swift#L259-L268 in the project linked by you do that.

But programs in java do not access the OS APIs directly, because java runs on many platforms. For each platform a (or several) native library between the java API and the OS API is implemented. This native library is either directly distributed with the java runtime package (e.g. non-exclusive windows audio), or distributed with the application and java is told to use this custom native library (in REW e.g. ASIO or WASAPI exclusive libraries).

CoreAudio native connector is implemented and distributed with java directly https://github.com/AdoptOpenJDK/ope...2b6/jdk/src/macosx/native/com/sun/media/sound, but the current source code does not set the kAudioDevicePropertyHogMode property to activate the hog mode https://github.com/search?q=repo:AdoptOpenJDK/openjdk-jdk8u AudioUnitSetProperty&type=code

Using the hog mode would require adding the hog-mode handling to the native library. That by itself would probably not be difficult, but the modified library would need to be compiled (and likely further modified to differentiate it from the original library) and distributed with REW separately. That's a major project.