Topic: Audio breaking / quality degradation on Windows

[saga]

Starting a few weeks ago (early January), we started receiving reports that audio stopped working in our application. We use both recording and playback capabilities. Unfortunately it's difficult to distill a clear picture of what's happening from customer reports, but here's some of the common things we have heard.

- It seems to affect only Windows, and only users with bluetooth headsets (Jabra and Sony brands have been mentioned). Potentially on Windows 11 is affected.
- We have had reports such as audio stopping after 15 minutes. Closing and re-opening the microphone in the app does not seem to help. Restarting the app does appear to help. Maybe because the speaker output is kept open even when closing microphone input.
- Customers usually say that all audio stops working, but one of my colleagues seems to have run into the same issue with a bluetooth Sony headset, in which his microphone quality suddenly dropped to something that resembled a low-quality 8 kHz audio signal or worse (we always record at 48 kHz). This effect persisted even after switching to a different microphone device, which makes me think this might even be a bug in the Windows audio stack. Needless to say, we have no code path that would intentionally lower the sample rate or apply other sorts of audio degradation. When my colleague encountered the issue, only restarting the app helped, but one thing we didn't check was whether changing the output device as well would fix the issue. We will try that the next time it happens.

I don't think there were any relevant changes to our app around the time this happened, and we also haven't updated BASS around that time (we are on 2.4.17.5). It smells a bit like a Windows update breaking things, but the first reports came in inbetween the monthly Windows updates, not right after the latest updates.

Have you heard anything similar from other BASS users? I think a BASS version with debug logs could be helpful, although I'm also not quite sure what could be logged there...

[Ian @ un4seen]

Haven't seen any other reports of this so far. When the audio stops working, is it affecting both playback and recording, and does it just go silent or totally stop, eg. does BASS_ChannelGetPosition still show progress on either playback or recording channels? Do BASS_SYNC_DEV_FAIL or BASS_SYNC_DEV_FORMAT syncs get triggered by it?

If you can reproduce the problem yourselves (or have contact with someone that can), one thing you could try to perhaps narrow it down is using DirectSound instead of WASAPI. You can do that via the BASS_DEVICE_DSOUND flag with BASS_Init (for playback) and the BASS_CONFIG_REC_WASAPI option (for recording).

[saga]

We do log (and automatically try to recover from) BASS_SYNC_DEV_FAIL events, but I cannot see any such logs in the reports we received so far. I'll see what I can do about adding BASS_SYNC_DEV_FORMAT logs for testing, and adding the DSound options. We did hear now from another colleague on Windows 10 experiencing the issue, and I'll be getting a similar Bluetooth headset to test with, so maybe (hopefully!) I have more things to report soon.

[saga]

I was now able to reproduce this issue on Windows 10 with a Jabra Evolve 65 SE headset (using the BT dongle provided with the headset, a Jabra Link 380). At the time it happened I did not add the extended logs yet, but that is done now, and I have also switched to DSound recording (playback remains WASAPI for now), so I will let you know if there are any logs or other changes. Playback was fine btw, only recording was affected.

Edit: Using the headset for several hours now, the DSound recording has not exposed any problems so far, while the problem showed up within half an hour or so when using WASAPI.

[Ian @ un4seen]

Edit: Using the headset for several hours now, the DSound recording has not exposed any problems so far, while the problem showed up within half an hour or so when using WASAPI.

Interesting. Please confirm whether the recording is going silent or stopping when using WASAPI (ie. is BASS_ChannelGetPosition still advancing), and are any BASS_SYNC_DEV_FAIL or BASS_SYNC_DEV_FORMAT syncs triggered? Please also confirm whether you're recording in the device's native rate (set in the Sound control panel), to see if it could be resampling-related.

[saga]

Back to using WASAPI, I still see no syncs being triggered. I did set up a timer checking the position of the recording channel every 500ms, and I did notice that it stalled for about a second after 45 minutes of recording. However, after that, the recording continued to work normally again. Is there anything in BASS_ChannelGetPosition that could cause such a stalled recording to become unstuck, or do you think this might just be a coincidence?
It might also be worth noting that when I encountered the stalled recording yesterday, the headset definitely remained in full-duplex mode, i.e. the audio quality was still reduced as it happens on most BT headsets without a proprietary codec.

[saga]

Some more observations: Since using the Bluetooth headset, I have noticed several times that after about 11.5 minutes, a weird noise (a short "beep") was inserted into the microphone signal, but the microphone signal continued to work afterwards. Now (still with the BASS_ChannelGetPosition checks every 500ms) I noticed something different: after 11.5 minutes, the recorded signal just turned into 100% digital silence.

[Ian @ un4seen]

Back to using WASAPI, I still see no syncs being triggered. I did set up a timer checking the position of the recording channel every 500ms, and I did notice that it stalled for about a second after 45 minutes of recording. However, after that, the recording continued to work normally again. Is there anything in BASS_ChannelGetPosition that could cause such a stalled recording to become unstuck, or do you think this might just be a coincidence?

I think that would have to be a coincidence, as BASS_ChannelGetPosition on a recording channel doesn't involve any system calls - it just returns the amount of data that has been processed. Does it seem to be making a difference every time, ie. the result is always different with and without it? If so, are there any other code changes along with the BASS_ChannelGetPosition call?

Some more observations: Since using the Bluetooth headset, I have noticed several times that after about 11.5 minutes, a weird noise (a short "beep") was inserted into the microphone signal, but the microphone signal continued to work afterwards. Now (still with the BASS_ChannelGetPosition checks every 500ms) I noticed something different: after 11.5 minutes, the recorded signal just turned into 100% digital silence.

Is that beep only present when using WASAPI recording, not DirectSound?

Please also confirm whether you're recording in the native sample rate (set in the Sound control panel and reported by BASS_RecordGetInfo), and if not, try that to see if it makes any difference.

[saga]

Does it seem to be making a difference every time, ie. the result is always different with and without it? If so, are there any other code changes along with the BASS_ChannelGetPosition call?

It does seem to be random, so I would agree that this was a conincidence. I just had another recording stall (after which all other audio devices could also not be recorded anymore!), and my code that would log when BASS_ChannelGetPosition calls wouldn't make any progress was never written, so it does appear that the recording was still running.

Is that beep only present when using WASAPI recording, not DirectSound?

It is present in a recording I made with DSound.

Please also confirm whether you're recording in the native sample rate (set in the Sound control panel and reported by BASS_RecordGetInfo), and if not, try that to see if it makes any difference.

We're always recording at 48kHz, and it would appear that full-duplex Bluetooth audio is restricted to 16kHz, as that's what Windows is showing. I suppose there is no way for BASS to record at 16kHz and then automatically upsample the signal? If not, I would have to change quite a lot of code to accomodate for the different sampling rate.

[Ian @ un4seen]

Is that beep only present when using WASAPI recording, not DirectSound?

It is present in a recording I made with DSound.

OK, seems like that's probably something unrelated then? Is it present when recording with other software too?

We're always recording at 48kHz, and it would appear that full-duplex Bluetooth audio is restricted to 16kHz, as that's what Windows is showing. I suppose there is no way for BASS to record at 16kHz and then automatically upsample the signal? If not, I would have to change quite a lot of code to accomodate for the different sampling rate.

When using WASAPI recording, BASS does record at the native rate and then resample. That doesn't happen when using DirectSound recording (DirectSound handles resampling). That's why I think it would be a good idea to try recording at the native rate (temporarily), to see whether the problem could be resampling-related. If it'll need a lot of work to do that in your code, perhaps you can reproduce the problem with the RECTEST.C example in the BASS package, and if so, add a 16000hz option to that?

[saga]

OK, seems like that's probably something unrelated then? Is it present when recording with other software too?

I haven't been able to verify other software yet. I tried to a bunch of recordings in Audacity via WASAPI and they didn't break.  I did mention this because it always appeared to happen around the same time no matter if DSound or WASAPI was used, so it could be that the device is always acting up at the same time, and DSound somehow manages to recover while WASAPI can't?

When using WASAPI recording, BASS does record at the native rate and then resample. That doesn't happen when using DirectSound recording (DirectSound handles resampling). That's why I think it would be a good idea to try recording at the native rate (temporarily), to see whether the problem could be resampling-related. If it'll need a lot of work to do that in your code, perhaps you can reproduce the problem with the RECTEST.C example in the BASS package, and if so, add a 16000hz option to that?

I'll be trying those options in the next few days. Since the issue is generally not 100% reliably reproducible, and since I'm not quite sure if multiple simultaneous recordings could influence the outcome, this does take a while.

[saga]

I had a closer look at the "beep" sound. We are recording in floating-point format, and it appears that the beep is not in the nominal -1 to +1 range, but the floating-point values are in the range of billions, which was definitely confusing some of our downstream audio processing, which explains at least some of the problems I was encountering.
However, I guess the main question now is where this beep is coming from, and why it produces values way outside of the nominal floating-point audio range.

[Ian @ un4seen]

I think I've found a bug in the recording resampling that could be causing the problems you're having. Please give this update a try and see if you still have them with it:

   www.un4seen.com/stuff/bass.zip

[saga]

Thanks for the update. So far I don't seem to see the issue anymore after several hours of testing. To clarify, would this update only address the "beep" sound or could it potentially also help with the recorded signal going completely silent for a while? And would this bugfix also be required on other platforms (macOS/Linux/iOS/Android)?

[Ian @ un4seen]

In my tests, the bug would cause distorted/squealing noises, but that happened quite a bit sooner than yours seem to be. So I'm not entirely certain it's related. Let me know if you do still hear them. This piece of code is only used on Windows (with WASAPI recording), so other platforms (or DirectSound recording) wouldn't be affected.

[saga]

So far after more than a day of testing, I cannot reproduce any of the issues I previously had. Now I just hope it's the same for our customers!

[saga]

I did have a look at the recording I made where it appeared that only silence was being recorded; it turns out that in this case, the silence was actually a whole bunch of NaNs! As mentioned before it recovered from recording NaNs after a minute or so, but it's interesting that it took that long.

[Ian @ un4seen]

Yeah, I think that would make sense. The problem was that a "double" value could get rounded-up in conversion to a "float", and potentially result in a value being read from beyond the end of a lookup table, which could happen to be a NaN. And if you have DSP set on the recording, then that could propagate them until all you have is NaNs.

[saga]

As I see there was another forum post where exactly the same fix helped, do you have any hypothesis why the issue is only showing up now, even though this BASS version has been out for a while (and we have been using it since at least around October)? Are there any external factors in the Windows environment that could play into this? I can hardly imagine that so many of our customers didn't apply any updates since October and now suddenly all applied the latest update of our software in January, or that all of them only started using headsets that require resampling at the same time. It's really quite a bunch of strange coincidences.

[Ian @ un4seen]

Yeah, it is a bit strange that the problem suddenly appeared now, but it does seem to depend on a specific sample rate ratio. I was only able to reproduce a problem with a 1:6 ratio, ie. 8khz input and 48khz output. Perhaps everyone received a crappy bluetooth headset for Christmas

I think the issue in the other thread you mention was actually something else. The WASAPI recording resampler also had an issue converting mono to stereo in the BASS 2.4.17 release, but that was fixed in an earlier update, so I suspect their problem would have been fixed by updating to the latest build even before the one above.