Windows audio (WASAPI) stops working after audio buffer size change

Windows
1

There is a pretty bad bug in the JUCE WASAPI implementation which causes audio streaming to stop working whenever the audio buffer size is changed from the audio devices dialog.

This can be readily reproduced in the JUCE demo itself.

  1. Open the Settings page and press the test button to ensure that you can hear audio.
  2. Select a different buffer size from the audio buffer size drop down.
  3. Press the test button again

After step 2 audio playback is broken.
To make it work again you have to select a different input or output and then it seems to reset itself. It seems like the device manager internal state is getting messed up when the buffer size is changed.

It would be great if this could be fixed since we expose the device settings dialog from our app.

Configuration as below if you need it:
Audio device diagnostics:

Current audio device type: Windows Audio
Current audio device: "Speakers (Realtek High Definition Audio(SST))"
Sample rate: 44100 Hz
Block size: 384 samples
Output Latency: 384 samples
Input Latency: 384 samples
Bit depth: 32
Input channel names:
Active input channels:
Output channel names:
Active output channels:

2

I can’t reproduce this issue at all. Anything specific with your setup? Can you try to reproduce this on a different computer?

3

Bizarre. Yes it happens on my laptop, desktop and other computers in QA as
well.
I first thought it was due to something specific in our app but the juce
demo has the problem as well.
It happens if I’m using onboard audio or USB audio. Try using a different
sample rate from the one on Windows. I’ll also follow up when I get to the
office and do some more tests.

Btw the juce wasapi implementation definitely has lots of bugs with
handling devices when the sample rate is different from Windows default
sample rate. I will log those separately. I’ll look into those after we
ship since I’ve been to busy fixing our own issues :slight_smile:

I have a lot of experience with wasapi since I did all of SONARs audio
implementation.

2 Likes
4

Sorry I was testing DirectSound by mistake. I can reproduce this now. I will have a look at this tomorrow.

1 Like
5

I’m insanely curious about these bugs! Looking forward to seeing them logged!

2 Likes
6

Thanks @fabian. Let me know what you find!

7

Thanks for reporting. I think this is now fixed on develop with commit 4f617f8.

8

This is awesome Fabian I’ll try it today. Btw we sent you invites to
download the RC. You should have got emails yesterday

9

Yes thank you. Jules and I are just playing with it now. :slight_smile:

10

Cool don’t break it :grin:

11

Btw you don’t have that build yet but we made some more tweaks for
performance. We switched to using the juce reverb instead of ours since
it’s much better on Android. With ours even the pixel couldn’t handle one
track with it on. iPhone was fine go figure. Android single core
performance is abysimal.

Cool don’t break it :grin:

12

Just confirmed that the buffer change bug is fixed. Nice job!