Enabling Windows Audio's SRC

I missed the discussion on this new feature and it slipped in to one of our recent releases without me realising. However, there seems to be some issues with one user and being able to change sample rate/buffer size: https://www.kvraudio.com/forum/viewtopic.php?f=22&t=553345

Is this a known issue? I tried it in my Parallels VM and was able to change the buffer size for all “Windows Audio” device types so I don’t know if this problem is device specific.
Anybody else seen this?

and in Low Latency Mode I can’t change the audio buffer size

  • It’s not a regression because Low Latency Mode wasn’t available before. Can they change buffer sizes in the mode that did exist (“Windows Audio”)?
  • IIUC it’s probably a limitation of Low Latency Mode

Ok, I’ll double check if the buffer size is only fixed in “Low Latency” mode.

The sample rate does seem to be fixed in all “Windows Audio” modes though:

There’s just one problem with this 11.1.21 Public Beta, I can’t change the sample rate anymore, it’s get stuck on 48000hz (in any option of “Windows Audio”)

That seems like a regression.

As far as I know, the sample rate of Windows Audio have always been fixed to whatever value is selected in the OS’ control panel for the particular audio device. In contrast to DirectSound where you can choose between more values (typically 44100, 48k, 88.2k, 96k etc).

The Audio buffer size however is stuck at 448 samples (10.2ms) in Windows Audio Low latency mode but selectable (in Juce control panel) in WA mode between 132 and 2018 samples. Hence I’ve never really understood why it’s called low latency… :slight_smile:

(Windows 10 version 2004, Focusrite external and Realtec integrated audio)

1 Like

I don’t think that was the case. At least from this user he’s reporting in older Waveform version he was able to choose different sample rates.

As you say, what’s the point of “Low Latency” mode if the buffer size is fixed at 448?

I don’t know about Waveform, but as long as I can remember dealing with the Juce framework (>6 years), I’ve never been able to change the sample rate for Windows Audio from inside the framework, e.g in the Juce demo. I guess it could depend on the actual hardware though, I`ve only used the it with four or five different audio devices.

1 Like

I think it depends on hardware. Something has definitely changed recently though.
In my tests with a Parallels VM:

Pre Low-Latency

Post Low-Latency:

In pre-low-latency, if I try to change assign the input as well as the input I get an error that the devices don’t share a common sample rate. In post-low-latency I get the option to do so though, is this because JUCE or the Windows layer is doing some sample-rate-conversion now so this configuration is allowed?

In Exclusive mode I used to be able to change the sample rate but now I can’t.


It would be nice to get some clarification on exactly how this behaviour has changed, at least so I can pass it on to my users. At the moment it’s like I’ve removed some functionality.

What you see directly relates to the topic of this discussion, which is the important one for me.

Background: for some reasons there are many devices that have 48k output and 44.1k input and JUCE didn’t support using them before, and now with enabling WASAPI’s built-in SRC it does! IIUC this only affects the plain “Windows Audio” mode.
Before, even if you implemented SRC yourself - JUCE wouldn’t support the audio because it only supports matching input and output sample rates. Now, you can use these devices with JUCE with WASAPI. Btw ASIO and macOS with the same devices (such as USB headsets) did work.

And the two additional recent changes to JUCE:

  • Exclusive mode was previously enabled only if you set some defines
  • Low latency mode is now also supported
2 Likes

Ok, thanks. That I understand.

But I don’t understand why my users now can’t change sample rate from JUCE for any of the Windows Audio device types. What has changed to disallow that and why?

Has anyone experience being able to change the sample rate in pre-low-latency builds on Windows before? I need to verify this behaviour before I go back to my user and tell them they were mistake, this was never possible.

In my experience, at least in “Exclusive Mode” I was able to change the sample rate:


Even if this was doing SRC to show me these sample rates, why is it not doing it now with this addition of SRC?

1 Like

Cool, so you have a reproducing setup then!

I suggest to bisect to find when the regression was introduced. It could be that one of the two changes of enabling SRC and enabling low latency audio somehow did it. If for example it’s some flags related to SRC somehow tell Windows to stop configuring sample rate in exclusive mode, then the solution could be to not enable that flag in that mode.

Are you actually able to open an exclusive device and select one of the different sample rates? I think the line responsible for this behaviour change is here:

Previously we were using the SUCCEEDED macro which will return true for anything other than S_FALSE, but the IsFormatSupported method can also return AUDCLNT_E_UNSUPPORTED_FORMAT for formats not supported in exclusive mode:

1 Like

Yeah, in pre-low-latency JUCE if I select the 8K sample rate it succeeds and playback sounds suitably low-fi.

I’d love to do bisecting and really drill in to this but I’ve got so much other stuff on my plate at the moment I don’t really have the time. I mainly just wanted to report a regression or at least get a statement about the new behaviour I can pas on to my users, even if the new behaviour has to stay.

1 Like

And it’s definitely in exclusive mode? You can verify by trying to play some audio through the same device using a different app like Spotify or something. If JUCE has exclusive control of the endpoint there won’t be any mixing so you won’t hear the other app.

Yeah, I get this message if I try and play a file with “Groove Music” (which I think replace Windows Media Player?).

If I switch to “Windows Audio” I don’t get that and the file plays fine alongside Waveform’s output.

2 Likes

Yeah that looks right. Thanks for confirming, will try to look into this when I get a chance.

3 Likes

OK, I think this should be fixed with the following commit:

When opening a stream in exclusive mode, the mix format returned by GetMixFormat() isn’t guaranteed to be supported by the endpoint so we need to call findSupportedFormat() afterwards to find a suitable format. Then the checks in querySupportedSampleRates() will be done using the supported format and we can get a full list of the supported sample rates.

I’ve tested this with a Windows VM and the advertised sample rates are now consistent with the behaviour before the recent changes, but it’d be good to know if this has fixed it for you too.

3 Likes

Great, thanks Ed, I’ll get this rolled in to a build I’m about to do and hopefully have some feedback from the user in a few days. Cheers for the quick turn around :+1:

2 Likes

I just tracked the buffer size not providing choices thing down in my own windows 10 laptop with a Realtek built-in audio driver. This is apparently due to the stupid Realtek driver… if you go to Device Manager, under Sound,video,game controller->Realtek Audio, right click on that, then do Update Driver, then do “Browse my computer for driver software”, then choose “Let me pick from available drivers”, then choose the option the ISN’T the Realtek driver, it will probably be High Definition Audio driver from microsoft. Then reboot. Then the Windows Audio Low Latency choice in the JUCE device manager will actually let you pick different buffer sizes, and it actually seems to work down to 128 (and have noticeably lower latency than before, so it actually does something).

This is one of those cases that using the generic microsoft driver is actually better than using a vendor’s driver apparently. You might want to pass that on to your user… it could help them.

3 Likes

Thanks for the info. I’ll pass this on to our users and hope it enables some more options for them.

Thanks for adding this. Unfortunately, I cannot get this to work properly for all devices. The audio input and output devices now do open without errors if I set up the playback and recording devices to have different sample rates in the Windows Control Panel. I tested with 44.1 kHz for the recording device and 48 kHz for the playback device. The problem is that whether playback nor recording work properly and the audio callback is called at a very reduced rate (around 1/10 of what’s required for the sample rate). I could reproduce this also with the Audio Settings demo in the JUCE DemoRunner app (the input level indicator is moving very slowly). This was with an old M-Track Eight audio interface from M-Audio: