McOsu
crt Jun 7, 2020 @ 12:14am
Period size explanation?
Using WASAPI exclusive mode with latency below 11ms causes extremely messed up crackling audio and also causes the game to randomly speed up and slow down. I'm not sure why I can't go below 11ms as I'm on Windows 10, not 7.

I wanted lower latency so I decided to mess with period size. I was able to get it down to 3ms before I started getting some kind of "bass can't init" error. I noticed setting period size seems to cause the game to ignore the other latency slider. It's probably placebo, but it feels like it might be lower latency... is it really 3ms? So what does period size actually do? I can't test latency by recording keypresses as WASAPI exclusive mode means Audacity can't access even the microphone.
Last edited by crt; Jun 7, 2020 @ 12:15am
Originally posted by McKay:
From the parameter documentation for BASS_WASAPI_Init()[www.un4seen.com]:

  • buffer = The length of the device's buffer in seconds or samples, depending on BASS_WASAPI_SAMPLES. This is a minimum and the driver may choose to use a larger buffer; BASS_WASAPI_GetInfo can be used to confirm what the buffer size is. For an output device, the buffer size determines the latency. With event-driven exclusive mode, there will be 2 buffers of this length, so the total buffer length is double.
  • period = The interval (in seconds or samples depending on BASS_WASAPI_SAMPLES) between callback function calls... 0 = use default. If the specified period is below the minimum update period, it will automatically be raised to that. This is ignored when the BASS_WASAPI_EVENT flag is specified, except in shared mode when buffer = 0 on Windows 10 (see remarks).

Shared mode usually has a fixed period of 10ms, but Windows 10 supports shorter periods, which allows smaller buffers and lower latency. A shorter period (and buffer) can be requested by setting buffer to 0 and period to the length wanted. If the requested period is lower than the device (or Windows) supports, then it will be automatically raised to the minimum supported. It will also be rounded up if it does not match the device's granularity. The actual period in use can be determined from the (minimum) amount of data that gets requested from the WASAPIPROC callback function. The shared mode period is a system-wide setting that affects all users of the device, particular those using event-driven buffering; they will be asked to provide data at the new period. If another process is already using a non-default period, then it will not be possible to set a different period until they finish; the existing period will have to be used in the meantime.


---


TLDR; On Windows 10, a 0 (yes, zero) size buffer with X period (as low as possible via trial & error, but not 0!) is a workaround for achieving low latency in shared mode. Expect random results depending on your hardware, drivers and other audio software interfering.
< >
Showing 1-2 of 2 comments
A developer of this app has indicated that this post answers the original topic.
McKay  [developer] Jun 7, 2020 @ 3:39am 
From the parameter documentation for BASS_WASAPI_Init()[www.un4seen.com]:

  • buffer = The length of the device's buffer in seconds or samples, depending on BASS_WASAPI_SAMPLES. This is a minimum and the driver may choose to use a larger buffer; BASS_WASAPI_GetInfo can be used to confirm what the buffer size is. For an output device, the buffer size determines the latency. With event-driven exclusive mode, there will be 2 buffers of this length, so the total buffer length is double.
  • period = The interval (in seconds or samples depending on BASS_WASAPI_SAMPLES) between callback function calls... 0 = use default. If the specified period is below the minimum update period, it will automatically be raised to that. This is ignored when the BASS_WASAPI_EVENT flag is specified, except in shared mode when buffer = 0 on Windows 10 (see remarks).

Shared mode usually has a fixed period of 10ms, but Windows 10 supports shorter periods, which allows smaller buffers and lower latency. A shorter period (and buffer) can be requested by setting buffer to 0 and period to the length wanted. If the requested period is lower than the device (or Windows) supports, then it will be automatically raised to the minimum supported. It will also be rounded up if it does not match the device's granularity. The actual period in use can be determined from the (minimum) amount of data that gets requested from the WASAPIPROC callback function. The shared mode period is a system-wide setting that affects all users of the device, particular those using event-driven buffering; they will be asked to provide data at the new period. If another process is already using a non-default period, then it will not be possible to set a different period until they finish; the existing period will have to be used in the meantime.


---


TLDR; On Windows 10, a 0 (yes, zero) size buffer with X period (as low as possible via trial & error, but not 0!) is a workaround for achieving low latency in shared mode. Expect random results depending on your hardware, drivers and other audio software interfering.
Last edited by McKay; Jun 7, 2020 @ 3:39am
McKay  [developer] Jun 7, 2020 @ 3:57am 
Originally posted by omega:
I'm not sure why I can't go below 11ms as I'm on Windows 10, not 7.
This is a hardware limitation. Your audio chipset and/or driver can't handle a smaller buffer. I've seen some devices go to ~7 ms, but the regular Realtek HD Audio ALC (e.g. ALC892) series only manage 11 ms.

Originally posted by omega:
Using WASAPI exclusive mode with latency below 11ms causes extremely messed up crackling audio and also causes the game to randomly speed up and slow down.
That's why the tooltip/text in-game says to increment the buffer until the crackling stops.
Last edited by McKay; Jun 7, 2020 @ 3:58am
< >
Showing 1-2 of 2 comments
Per page: 1530 50

Date Posted: Jun 7, 2020 @ 12:14am
Posts: 2