ASIO Device : All Sampling Rates not supported by Juce


#1

Hello All,
I am currently working with the fireface audio device. This device supports 32Khz - 192 Khz sampling rates. I am able to set those sampling rates in the deivce’s control panel.

But, When I open the device via "AudioDeviceSelectorComponent " in juce demo project(Just enabled the asio device alone additionally), the sampling rate selection box in the control panel is disabled automatically. Also, in the deviceSelectorComponent, only sampling rates from 44 Khz are selectable. 32Khz is missing

Do you guys have any clue on the issue?? Could anyone please help me on this??

Update:

I saw in juce_win32_ASIO.cpp the possible sample rates as

const int possibleSampleRates[] = { 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000 };

Do, any one of know why 32khz is not present in this array?? We have use case(to test all possible sample rates) to use 32 Khz which is supported by the ASIO device.

The ASIO device in my case is RME fireface UC.


#2

We could add 32K to the list, but the general plan was to not bother with rates that users would be ill-advised to choose…


#3

What’s the behaviour if the device is already set to 32kHz before you start a JUCE app?


#4

IIRC the list is only used as the set of suggested rates that the UI should offer to a user. It won’t stop the device reporting a current rate that isn’t on the list.


#5

@jules Yes. It doesnt stop the device but changes the device sample rate from 32k to 44.1 khz automatically. Is it possible to include 32k to the list since we are working on speech and not audio. So, 32k will be suitable for us.

Also, I see that the Buffer size of audio block, when changed from the control panel is not reflected in the “audioDeviceAboutToStart” method. For example, If I change the buffer size from 128 to 256 in the device control panel, “audioDeviceAboutToStart” method is called again but again with the same old 128 buffer size.

I checked in juce_win32_ASIO.cpp file to see what the device driver is reporting to juce.
long refreshBufferSizes()
{
return asioObject->getBufferSize (&minBufferSize, &maxBufferSize, &preferredBufferSize, &bufferGranularity);
}
It returns properly the new buffer size of 256. But somehow, the same is not reflected when preparetoPlay method is called.

Do you have any info on this??


#6

Sure, I’ll add 32K to the list, I guess it’s not harmful to offer more options.

Not really sure about the buffer size - the ASIO code has been pretty solid over many years now, so I’d expect any weirdnesses like this to be fairly device-specific. Since we can’t reproduce it here without the same hardware, perhaps if you can suggest a fix that makes it work there, and we can sanity-check that as a possible solution?