# ASIOAudioIODevice::getCurrentSampleRate() returning wrong value **URL:** \ **Category:** General JUCE discussion\ **Created:** [November 13, 2015, 11:11am UTC](https://forum.juce.com/t/asioaudioiodevice-getcurrentsamplerate-returning-wrong-value/15940 "2015-11-13T11:11:45Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![gphofa](https://avatars.discourse-cdn.com/v4/letter/g/3ec8ea/32.png) [@gphofa](https://forum.juce.com/u/gphofa)\ **Post date:** [November 13, 2015, 11:11am UTC](https://forum.juce.com/t/asioaudioiodevice-getcurrentsamplerate-returning-wrong-value/15940/1 "2015-11-13T11:11:45Z")
ASIOAudioIODevice::getCurrentSampleRate() does sometimes return a wrong value. When the samplerate of an audio device that is open in a JUCE application is changed by a different application, this change will not be reflected in the currentSampleRate variable that is returned by this function. Maybe in juce\_win32\_ASIO.cpp it should be changed like this? ``` double getCurrentSampleRate() override { currentSampleRate = getSampleRate(); return currentSampleRate; } ```   ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [November 13, 2015, 3:57pm UTC](https://forum.juce.com/t/asioaudioiodevice-getcurrentsamplerate-returning-wrong-value/15940/2 "2015-11-13T15:57:26Z")
Updating a value inside a function that is supposed to already know the correct value is something I'd be very suspicious of.. Looking at the code, it looks to me that maybe it just needs to ask the driver for the sample rate later on in the process - e.g. does your driver work if you add this at line 564? ``` readLatencies(); currentSampleRate = getSampleRate(); // <-- new line asioObject->getBufferSize (&minSize, &maxSize, &preferredSize, &granularity); deviceIsOpen = true; ``` ---
**Author:** ![gphofa](https://avatars.discourse-cdn.com/v4/letter/g/3ec8ea/32.png) [@gphofa](https://forum.juce.com/u/gphofa)\ **Post date:** [November 16, 2015, 12:35pm UTC](https://forum.juce.com/t/asioaudioiodevice-getcurrentsamplerate-returning-wrong-value/15940/3 "2015-11-16T12:35:21Z")
That does not help. As the ASIOAudioIODevice is not reset or re-opened, there is no call to ASIOAudioIODevice::open(). When the samplerate is changed e.g. from Cubase, only the callback function AudioDeviceManager::audioDeviceListChanged() is triggered. This will call currentAudioDevice-\>getCurrentSampleRate(), which returns the old value. My ASIO device is an RME Babyface.   Regards, Gregor   ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [December 1, 2015, 3:31pm UTC](https://forum.juce.com/t/asioaudioiodevice-getcurrentsamplerate-returning-wrong-value/15940/4 "2015-12-01T15:31:35Z")
Don't understand this.. You say that audioDeviceListChanged() is called, so the device must call sendASIODeviceChangeToListeners(), which is only called immediately after a call to open(). So I don't see how it can not be calling open() ? ---
**Author:** ![gphofa](https://avatars.discourse-cdn.com/v4/letter/g/3ec8ea/32.png) [@gphofa](https://forum.juce.com/u/gphofa)\ **Post date:** [December 10, 2015, 9:01am UTC](https://forum.juce.com/t/asioaudioiodevice-getcurrentsamplerate-returning-wrong-value/15940/5 "2015-12-10T09:01:41Z")
The call to audioDeviceListChanged() is originated from DeviceChangeDetector::timerCallback() which will call WASAPIAudioIODeviceType::systemDeviceChanged().  So the message is more or less an indirect "something has changed" message. It is not coming from the ASIO device itself, which might be a problem of the driver. The problem only occured with the RME Babyface and not with other interfaces. Anyway in this case it happens that the samplerate that is returned from getCurrentSampleRate() is wrong which could be avoided as suggested above.   ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [December 10, 2015, 9:16am UTC](https://forum.juce.com/t/asioaudioiodevice-getcurrentsamplerate-returning-wrong-value/15940/6 "2015-12-10T09:16:41Z")
Your suggested fix isn't enough because when the sample rate changes, the device **must**  be restarted, so that any clients get an audioDeviceAboutToStart callback. If getSampleRate just suddenly starts returning a new value, then any synths or audio playback wouldn't pick this change up, would continue playing at the wrong speed. So I was trying to look for a way to force a device reset. On your device, surely the sampleRateChangedCallback() callback gets called? That should trigger a call to resetRequest, and then open(), etc.. ? ---
**Author:** ![gphofa](https://avatars.discourse-cdn.com/v4/letter/g/3ec8ea/32.png) [@gphofa](https://forum.juce.com/u/gphofa)\ **Post date:** [December 10, 2015, 10:48am UTC](https://forum.juce.com/t/asioaudioiodevice-getcurrentsamplerate-returning-wrong-value/15940/7 "2015-12-10T10:48:24Z")
In my application it is sufficient to reset some internal stuff when the samplerate was changed. I did not need to restart the device. But I agree that this might not be sufficient as a general sulution. Unfortunately sampleRateChangedCallback() also does not get called in this case. I just updated the RME driver but the problem remains. Maybe I should contact them, too.   ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [December 10, 2015, 11:44am UTC](https://forum.juce.com/t/asioaudioiodevice-getcurrentsamplerate-returning-wrong-value/15940/8 "2015-12-10T11:44:08Z")
If the driver is changing its rate without calling that method then yes, it definitely sounds like their bug! Does it not call any of the ASIO callbacks when this happens? e.g. asioMessagesCallback with a kAsioResetRequest or kAsioResyncRequest or something? I can't see how any apps could handle this unless it does _something_ to tell it about this.. ---
**Author:** ![dparakh](https://avatars.discourse-cdn.com/v4/letter/d/f4b2a3/32.png) [@dparakh](https://forum.juce.com/u/dparakh)\ **Post date:** [May 16, 2016, 8:49am UTC](https://forum.juce.com/t/asioaudioiodevice-getcurrentsamplerate-returning-wrong-value/15940/9 "2016-05-16T08:49:18Z")
I ran into a similar problem with an RME MadiFace USB. Here is what I have found: [For simplicity, I’m using Lo to group 44.1 and 48KHz, and Hi to group 88.2 and 96K] - When RME’s SampleRate is changed between a “Lo” group and “Hi” group - for example from 44.1 to 96, or from 48 to 96, 44.1 to 88.2, etc… the ASIO driver sends the latencies changed callback (kAsioLatenciesChanged). - When RME’s SampleRate is changed within the Lo or Hi groups (44.1 -\> 48, or 96 -\> 88.2, etc.) the RME driver does not send any callbacks, neither through the asioMessage callaback, nor though the sampleRateDidChange callback). What’s interesting is that Cubase 7 is able to detect this change even when I see no callbacks from the RME driver. On the other hand, other DAWs such as Reaper are not able to detect this change either. I’m suspecting that Cubase is doing one of two things to trigger their SR change handling logic: - Polling the getCurrentSampleRate() from a timer. - Calculating the actual SampleRate (based on the OS timer) when it gets the bufferSwitch/bufferSwitchTimeInfo callbacks. Thanks. Devendra.