sampleRateHasChanged on OSX…


#1

The JUCE Demo and Host demo both don’t update their audio device settings if another app changes the sample rate for the current device…

For example, run either the JUCE demo or the JUCE host and also run Addictive Drums 2 (AD2) standalone (another JUCE app)… with all apps set to Built-In sound and 44100 Hz sample rate all apps play back fine… in AD2 change the sample rate to 96kHz… neither the JUCE demo or host update their sample rates… so they playback at the wrong pitch. XLN probably have a ChangeBroadcaster from AudioDeviceManager notify them when the sample rate changes… 'cause if you change the sample rate in the JUCE demo or host, AD2 updates it’s sample rate correctly.

Could you add this to the demo and host?

Thanks,

Rail


Listening to sample rate changes
External Changes to AudioDeviceManager Sample Rate
#2

… actually poking around the code… it looks like AudioDeviceManager doesn’t send a change message… in juce_mac_CoreAudio.cpp, timerCallback() is triggered by a change in the other app’s sample rate… but it doesn’t appear to update the AudioDeviceManager.

Rail


#3

AFAICT when the sample rate changes, it should restart any callbacks - that happens at line 748.

(though TBH I'm not sure why changing the sample rate in another app would make a difference anyway because the driver should treat each app separately..?)


#4

Yeah, line 748 is reached, but AudioDeviceManager::CallbackHandler::audioDeviceAboutToStart() isn’t always triggered… which means AudioDeviceManager::audioDeviceAboutToStartInt() isn’t called.

Yeah, I tested using AD2 and BFD3 (both standalone) and switching the sample rates in either didn’t affect the other (AD2 uses JUCE, BFD3 doesn’t)… but when I tried to do a screen capture with Jing using the same audio device as AD2 and the JUCE Host then Jing would abruptly stop capturing when I changed the sample rate…

XLN have a demo of AD2 you can check out: http://www.xlnaudio.com

I’ve seen similar issues using the UA Apollo Twin SOLO (which uses JUCE) and the JUCE Host.

If you run the JUCE Host and load the JUCE Demo plugin and set the sample rate in the JUCE Host then start switching the sample rate in AD2 Standalone and set breakpoints in the Host:

play C5 after changing the sample rate and listen to the pitch and watch to see which breakpoints are called. As you say the 2 apps probably should run independently, but there must be something static in common.

Cheers,

Rail


#5

The physical hardware on the audio interface can only run at one sample rate at a time.  the drivers don't do any audio conversion.  they just tell the audio device what sample rate to set its physical clock at.     Each application can talk to the driver and request that the driver change sample rates.   but the hardware itself can only operate at one sample rate at a time, so the driver will only allow one sample rate to be used.  think about it, they only have one clock inside, controlling all of the conversion chips.    

 

This myth that hardware can operate at multiple sample rates simultaneously needs to be dismissed once and for all.   Shoot an email to Apogee, MOTU, mAudio, etc.   they'll tell you the same thing. 


#6

Yes, we know that… The problem is if another JUCE app changes the sample rate the others don’t get a callback to change theirs in prepareToPlay()… So their pitch is wrong.

Rail