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?
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”)
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…
(Windows 10 version 2004, Focusrite external and Realtec integrated audio)
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.
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
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:
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:
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.
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.
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.
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
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.
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: