# BR: MacOS non standard sample rates can lead to incorrect display in AudioDeviceManager

**URL:** <https://forum.juce.com/t/br-macos-non-standard-sample-rates-can-lead-to-incorrect-display-in-audiodevicemanager/50499>\
**Category:** MacOSX and iOS\
**Created:** [March 7, 2022, 12:47pm UTC](https://forum.juce.com/t/br-macos-non-standard-sample-rates-can-lead-to-incorrect-display-in-audiodevicemanager/50499 "2022-03-07T12:47:07Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![andrewj](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/andrewj/32/13428_2.png) [@andrewj](https://forum.juce.com/u/andrewj)\
**Post date:** [March 7, 2022, 12:47pm UTC](https://forum.juce.com/t/br-macos-non-standard-sample-rates-can-lead-to-incorrect-display-in-audiodevicemanager/50499/1 "2022-03-07T12:47:07Z")

</div>

Hi JUCE team (especially @t0m),

I’ve got a user report of the AudioDeviceManager showing the incorrect sample rate (offset by one position from the correct value in the combobox). I haven’t got an exact repro, but it was observed under the following conditions:

- Audio device had non standard sample rates available (i.e. not in the default list)
  - RME DigiFace USB (which supports 64 kHz and 128 kHz rates as per screen shot)

- User frequently changed sample rate using AudioDeviceManager, and
- User also changed sample rate from the device’s control panel
  - In this case the audio device does set the non standard rate and operate correctly
  - However, at least sometimes the combobox is showing the wrong sample rate

JUCE version was dev branch immediately after [this commit](https://github.com/juce-framework/JUCE/commit/de97e53a871b1e175bd2ac95cd222bd4decf02eb) (which may ironically be where this can be fixed!).

![Audio MIDI Sample rates](https://us1.discourse-cdn.com/flex026/uploads/juce/original/2X/d/d10415cae9527124d063edccaf3b8cb4f3ca774f.png)

---

<div class="post-metadata">

**Author:** ![kcoul](https://avatars.discourse-cdn.com/v4/letter/k/3ab097/32.png) [@kcoul](https://forum.juce.com/u/kcoul)\
**Post date:** [March 9, 2022, 9:22pm UTC](https://forum.juce.com/t/br-macos-non-standard-sample-rates-can-lead-to-incorrect-display-in-audiodevicemanager/50499/2 "2022-03-09T21:22:35Z")

</div>

I was the one who contributed adding 24kHz sample rate for airpod pros - I figure this situation is similar - the need to add 64kHz and 128kHz rates if _any_ device can support them. The bigger problem is that there are hard-coded arrays of sample rates in the code in the first place, but it would be a much bigger refactor to remove them entirely.

There must have been no way for your user to actually use the Digiface at those two unsupported sample rates with anything built using JUCE, and settings them from the OS panel would probably result in undefined behaviour (an off-by-1 or even off-by-2 sample rate would make a lot of sense in this case).

---

<div class="post-metadata">

**Author:** ![andrewj](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/andrewj/32/13428_2.png) [@andrewj](https://forum.juce.com/u/andrewj)\
**Post date:** [March 10, 2022, 9:11am UTC](https://forum.juce.com/t/br-macos-non-standard-sample-rates-can-lead-to-incorrect-display-in-audiodevicemanager/50499/3 "2022-03-10T09:11:16Z")

</div>

Hi Kieran - agreed on the hard coded array.

The user (incidentally the device manufacturer) was able to use these sample rates. I’m guessing when they select the sample rate in their own control panel, the device sends a reset, which triggers an update and then the correct sample rate is retrieved by getNominalSampleRate().

Perhaps updateDetailsFromDevice() should check whether the nominal sample rate is not a member of newSampleRates and add it if it isn’t already there.

---

<div class="post-metadata">

**Author:** ![andrewj](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/andrewj/32/13428_2.png) [@andrewj](https://forum.juce.com/u/andrewj)\
**Post date:** [March 31, 2022, 11:24am UTC](https://forum.juce.com/t/br-macos-non-standard-sample-rates-can-lead-to-incorrect-display-in-audiodevicemanager/50499/4 "2022-03-31T11:24:29Z")

</div>

Polite bump @t0m

---

<div class="post-metadata">

**Author:** ![t0m](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/t0m/32/16413_2.png) [@t0m](https://forum.juce.com/u/t0m)\
**Post date:** [April 1, 2022, 7:10pm UTC](https://forum.juce.com/t/br-macos-non-standard-sample-rates-can-lead-to-incorrect-display-in-audiodevicemanager/50499/5 "2022-04-01T19:10:47Z")

</div>

Thank you for reporting.

> <https://github.com/juce-framework/JUCE/commit/1f29416fd0ea81746853e1fe5cf177e0dc7ad16e>

---

<div class="post-metadata">

**Author:** ![kcoul](https://avatars.discourse-cdn.com/v4/letter/k/3ab097/32.png) [@kcoul](https://forum.juce.com/u/kcoul)\
**Post date:** [April 1, 2022, 10:09pm UTC](https://forum.juce.com/t/br-macos-non-standard-sample-rates-can-lead-to-incorrect-display-in-audiodevicemanager/50499/6 "2022-04-01T22:09:59Z")

</div>

Great solution!

---

<div class="post-metadata">

**Author:** ![andrewj](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/andrewj/32/13428_2.png) [@andrewj](https://forum.juce.com/u/andrewj)\
**Post date:** [April 2, 2022, 7:13am UTC](https://forum.juce.com/t/br-macos-non-standard-sample-rates-can-lead-to-incorrect-display-in-audiodevicemanager/50499/7 "2022-04-02T07:13:32Z")

</div>

Excellent, thanks Tom!
