ASIO Sample Rate Selection Oddities

General JUCE discussion
1

Hi Jules,

When trying to initially configure ASIO4ALL v2 by selecting the sample rate 88200 Hz, or 176400 Hz, I get the “Device didn’t start correctly” message. (leading me to a “<>” device)

I’m able to switch to the “Windows Audio” device type, and have everything work fine. But what’s befuddling is that when switching back to “ASIO” again, I get the current sample rate, and the two others that give me the alert message, to choose from… and I’m able to select either, successfully configuring ASIO, but with no output!

Initial sample rate list for ASIO:
[attachment=0]ASIO - Initial Sample Rate List.png[/attachment]

List of rates when switching back to ASIO, after going to WASAPI:
[attachment=1]ASIO Broke.png[/attachment]

2

Have you tried turning on JUCE_ASIO_DEBUGGING? Might give a few clues as to what’s failing.

3
4

I tested these rates in other DAWs (FL Studio, Audition, Reaper (x64), Studio One 2 (x64)); those two specific sample rates just don’t work with ASIO4All v2… There might just be a bug in the driver. :?

Is anybody else able to confirm this strange ASIO behaviour?

5

As far as I can tell there are still some issues here.

Figured it was my app, but I have tested in Juce Demo

RME FireFace (And incomming reports about other RME devices):

When changing sample rates it complains that "Can't create I/O Buffers"

The error code from the ASIO driver is ASE_InvalidParameter

Re-selecting the device after this error, makes it work.

Also when fiddeling with this from time to time I get a "Device didn't start correctly" message.

 

Focusrite iTrack Solo

Similar issues but ASIO error is ASE_InvalidMode

 

Zoom Tac-2

When selected, we get message Sample Rate could not be set.

 

Anyone else can confirm this? Or got any tips.

 

How do I turn on the JUCE_ASIO_LOG feature, that might help.?

 

 

6

How do I turn on the JUCE_ASIO_LOG feature, that might help.?

Simply place this in one of your projects' AppConfig.h:

#define JUCE_ASIO_DEBUGGING 1
7

Thank you jrlanglois.

I have stepped through the code, several times, had a cup of coffie and I think I know what the problem is.

At least with the RME stuff, but if I'm correct this must apply to many drivers out there.

As said before the issue is with creating the I/O buffers, and it replys with the error ASE_InvalidParameter.

The thing is when you change sample rate from 44800 to let say 96000 the device changes the number of availabe channels.

in 44.1 & 48 it has 18 in /18 out. But if you  change to 88.2 it has  14/14, and in 192 it has 10/10.

The problem is (in juce_win32_ASIO) that the number of channels is quieried before the sample rate is set.

 

As far as I can tell the flow is something like this:

* Get number of IO

* Ask to change Sample Rate, sample rate is set (Now the device has change the number of channels available)

* Ask to Create buffers, with the old amount of channels.

 

Do you guys think I'm on to something?

 

 

8

I can confirm this. We've had many users with issues with the same device. I can add Roland devices to the list:

RME in general.
Zoom Tac-2
Focusrite iTrack Solo
Roland Studio Capture  
Roland Quad Capture  

This is using a one year old juce version, seems like the same problem as described. 

9

Thank you OBO for verifying the issue

I'm pretty up to date using git (update once a week or so)

Ok I have looked some more at this.

For once to reproduce in the demo, you need to select the correct driver, enable all outputs (or inputs).
( The bug will also show if you use "Enable Default Input" in your app, as it will enable all I/O)

After enabeling all inputs or outputs, change samplerate from 44100 to 96000, and observe the error message.

 

I made a quick "fix" in juce_win32_ASIO.cpp just for testing:

in the ASIOAudioIODevice::open function:

after :


        updateClockSources();
        currentSampleRate = getSampleRate();
        error.clear();
        buffersCreated = false;
        setSampleRate(sampleRate);

I added:


        //reset after sample rate change
        err = asioObject->getChannels(&totalNumInputChans, &totalNumOutputChans);
        jassert(err == ASE_OK);

        currentChansOut.clear();
        currentChansIn.clear();
        inBuffers.clear(totalNumInputChans + 1);
        outBuffers.clear(totalNumOutputChans + 1);

This is just copy paste from earlier in the function to reset totalNumInputChans and totalNumOutputChans.

This seems to fix the bug. But I guess Jules will need to look at this since I now got other issues in my app now for some reason. So my "solution" is probably not the correct way to fix it.

Also in the demo, the buffersize combobox de-selects it self for some reason when the sample rate changes

 

10

Sorry one wrong report there, the Zoom Tac-2 issue is actually on OSX, so no asio to blame there

11

So my "fix" does not actually work, it messes up the buffers somehow and I get an error when the device is freed.

But it does prove that there needs to be changes made to the way samplerate / number of channels are set.

I would rate this as a severe bug, as it makes Juce applications not work with some of the major audio device brands.

Hope someone with more knowlage of the asio code can look in to this.

 

12

The order in which you call functions when opening an ASIO device is very fragile - when I first wrote this code years ago I remember there were devices that would crash if you didn't ask for their buffer size, etc in the correct order. So I can certainly believe that there may be devices that aren't well-behaved, but not sure what I can suggest as a change, since I can't actually test this myself, and it's largely a case of trial-and-error in finding fixes like this..

13

Yes you would bellive that when creating ASIO steinberg would be a little bit more clear on things.

Anyhow, the thing is that the code can´t asume that the number of channels are the same after the sample rate has been set (changed)

in the ASIOAudioIODevice::open function:

there is this chunk:

updateClockSources(); 
currentSampleRate = getSampleRate(); 
error.clear(); 
buffersCreated = false; 
setSampleRate(sampleRate);

This gives the device a new sample rate

Then a bit further down there is this:

       JUCE_ASIO_LOG ("creating buffers: " + String (totalBuffers) + ", " + String (currentBlockSizeSamples));

        err = asioObject->createBuffers (bufferInfos, totalBuffers, currentBlockSizeSamples, &callbacks);

But now it is asking for more channels then the device actually has, becuase the number of IO was queried before the sample rate change.

So I guess we need to get the number of channels each time the sample rate changes.

 

I could send you a RME device if that helps (Although I´m sure someone in London has one)

14

FYI I just added some changes that may help with this..

15

This seems to be fixed now. Thank you.

See that you have comitted som changes related to Zoom as well, will report back on that one