Topic: Bug or Intended Behavior with Device Configuration on Windows?

[srmenzies]

Coming from this issue in osu!lazer: https://github.com/ppy/osu/issues/12056.

My comment from that issue:

I believe I have been able to recreate this bug, which seems to be caused by Windows' Audio management keeping BASS from being able to set certain device properties itself, and instead using whatever the system chooses to, specifically on Device update period and buffer length. This also lines up with previous statements of reinstalling Windows or moving to the 2016 BASS dll, since the functionality to change the device update period only came to BASS in January 2019, so I suspect that some change in how BASS interacts with that was significantly changed at that point.

Luckily there is BASSWasapi, which allows these settings to be controlled through requests to the windows audio session, and with implementing Wasapi.Init(), it is possible to specify these values as shown in this video, where I first set both values to a massive 1000ms to exaggerate the offset more, but I found lower combinations here to be fairly similar to what was originally reported.

I have placed a pull request in osu-framework to address this issue by including ManagedBass.Wasapi and adding a little bit of logic in InitBass to try to Initialize through Wasapi first on Windows systems, with set values that seem to be known to work (10ms Device buffer and 5ms Device Update Period), before falling back to the same method currently used if Wasapi fails. It can be found here. I'm not particularly experienced with C# myself, so feel free to let me know if there are better ways of implementing this, but I hope my investigation was useful nonetheless.

Specific Info Relating to BASS:
While looking into this bug which seems to be caused by (or at least can be replicated by) the Device Period and/or Device Buffer values being too high, which appears to be the case on certain Windows systems, it would seem that setting these config values(solely with BASS, not using Wasapi) don't have any effect at all in newer versions of BASS, where as in some older versions (reported as 2016, so possibly related to the addition of the Device Period being adjustable in 2019?), apparently something does reduce these values or prevent Windows from using the same values which cause the issue. The issue hasn't been reported on any systems other than Windows, and these settings do work fine on Linux, which certainly leads me to believe that it is due to some strange interaction with Windows' Audio Sessions, and through the use of Wasapi.Init() from BASSWasapi, it is still possible to manually set these values on Windows systems.

My Question:
For current versions of BASS is this the intended behavior? Or for these situations is using BASSWasapi the best way to set these values on Windows systems?

[Ian @ un4seen]

It isn't entirely clear to me what the problem is, but if switching to an old BASS version from 2016 prevents it happening then it seems like it may be related to WASAPI output, as BASS always used DirectSound output back then. WASAPI is used by default now (on Vista and above), but DirectSound is still available via the BASS_DEVICE_DSOUND flag. Please try adding that flag to your BASS_Init call with the latest BASS version and see whether the problem still happens then.

After checking that, please also see if you can reproduce it with this latest build/beta (with and without the BASS_DEVICE_DSOUND flag):

   www.un4seen.com/stuff/bass.zip

[srmenzies]

At the moment I seem to be able to set the device period and buffer just with the BASS config with both the latest and beta versions, with and without the DSOUND flag, but it's definitely nice to know about since that is a much easier solution than having to go through the BASSWasapi addon in order to specify those, and I'm going to continue trying to figure out if I can replicate that behavior from before.

To try and clarify the actual problem I think is being encountered, it's some sort of a desync/delay in how long it takes for the sound to actually play. I seem to be able to reproduce this desync with larger values for the device buffer or update period, so I suspect that the delay is being caused by the time it takes to update the device buffer. My reasoning for thinking this is related to WASAPI is because in the BASS documentation for these config settings, and as I previously saw myself, it says that these settings usually won't have an effect on Windows systems, and that Windows will decide the actual value. The theory is that Windows is setting these values a bit too high for our case in some cases, and causing a slight desync. If this is the case, then originally I believed that the solution would be to use the BASSWasapi addon in order to tell WASAPI that we want lower values, although specifying to go through DirectSound might be the better solution.

[ppy]

Just to clarify, here is a summary of the issue reported to date, in a hope that it may be able to help pinpoint the potential point of failure:

- multiple users have reported the game clock going out of sync, which means the time reported by the bass track (via `BASS_ChannelGetPosition`) gets more and more out of sync with expectations over time.
- pausing the track playback and starting again seems to temporarily resolve the issue.
- there have been reports that updating audio drivers or even BIOS firmware can resolve the issue (https://github.com/ppy/osu-stable-issues/issues/306#issuecomment-636396608).
- this has been reported over two completely different code bases, starting in 2020 but continues to be an issue

The wildcard here is the reported fix in this thread, which is that manually setting WASAPI startup settings somehow resolves the issue (although this has only been confirmed by the one user above).

[Ian @ un4seen]

Are you comparing the stream's position with the wall clock, and they're drifting further apart over time? If so, that sounds like the soundcard might not be going exactly at its specified rate, eg. not exactly 44100 Hz. When that happens, you can compensate for it with the stream's BASS_ATTRIB_FREQ setting, ie. raise it slightly if the stream is falling behind, or lower it if the stream is getting ahead. I wouldn't expect buffer lengths to make any difference, unless the drifting is caused by buffer underruns (are little gaps/skips heard?).