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 
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:
