Sound is delayed by a few seconds

[Chris]

Got it!

Code: Select all

AL lib: (II) alc_initconfig: Supported backends: mmdevapi, dsound, winmm, null, wave
AL lib: (II) ReadALConfig: Loading config C:\Users\Mynameislol\AppData\Roaming\alsoft.ini...
AL lib: (II) LoadConfigFromFile: found 'sample-type' = 'float32'
AL lib: (II) LoadConfigFromFile: found 'channels' = 'ambi3'
AL lib: (II) LoadConfigFromFile: found 'frequency' = '48000'
AL lib: (II) LoadConfigFromFile: found 'period_size' = '8192'
AL lib: (II) LoadConfigFromFile: found 'periods' = '16'
AL lib: (II) LoadConfigFromFile: found 'resampler' = 'bsinc'
AL lib: (II) LoadConfigFromFile: found 'stereo-mode' = 'speakers'
AL lib: (II) LoadConfigFromFile: found 'stereo-encoding' = 'uhj'
AL lib: (II) LoadConfigFromFile: found 'ambi-format' = 'acn+sn3d'
AL lib: (II) LoadConfigFromFile: found 'decoder/hq-mode' = 'true'

This seems to be the problem. Any reason you've configured OpenAL Soft like this?

In particular, you're setting a sample rate of 48khz with a period size of 8192 and 16 periods. That means each period lasts for about 186 milliseconds, with 16 periods (for a total of 2.97 seconds). Something else of note is that you set the channel configuration to third-order ambisonics output. I'd be very surprised if that's how your device is configured, and I don't think any of the Windows backends will even support it anyway. I'd strongly suggest leaving the options at their default unless you know for sure what the option is doing and why you need it that way.

Also, your device seems to be configured for 192khz playback in Windows. Unless you're doing pre-mastering audio production work, this is serious overkill. And even if you are, it may be better to reconfigure the device to 48khz while playing games and the like. Such a high sample rate is putting a bigger strain on the CPU since it has to process 4x as many samples, and it prevents things like HRTF from working since the included datasets only support 44.1 and 48khz (and even if you made a 192khz dataset, the main mixing loop will see a 16x CPU increase to retain the same quality).

[Mynameislol]

Strange, i havn't changed the perioid size at all, i don't even know how to change that, and i'm pretty sure i've disabled ambisonics output, as there's no option for it.

I don't have any use for HRTF as i'm using speakers, and i both produce music and master it, the 192khz is only to raise the noise floor. CPU usage isn't a problem, i havn't had any issues with that.

So, the solution seems to be changing the period size?

[Chris]

Strange, i havn't changed the perioid size at all, i don't even know how to change that, and i'm pretty sure i've disabled ambisonics output, as there's no option for it.

If you haven't specifically created/edited alsoft.ini, nor run alsoft-config.exe before, then something else probably tried to make it for you. However, you can just delete C:\Users\Mynameislol\AppData\Roaming\alsoft.ini to set everything back to defaults. Or alternatively, edit it (it's a plain text file) and remove everything besides the resampler and stereo-encoding options if you wish (the sample-type, channels, and frequency settings are detected from the system, there's no need to explicitly set them).

I don't have any use for HRTF as i'm using speakers, and i both produce music and master it, the 192khz is only to raise the noise floor.

The sample rate just controls the maximum representable frequency (half the sampling rate, as per the sampling theorem), it's the bit depth controls the noise floor (which is 32-bit float internally for the mix). In fact, using a 192khz sample rate for playback can actually create noise if you're not using high quality specialized equipment -- a DAC that can properly reconstruct analog signals from 192khz audio (if the DAC is internally just doing 44 or 48khz sample rates, the 192khz stream is being resampled down which is just going to create noise from lossy filters), and speakers that handle super high frequencies (speaker drivers have a limited response range and generate noise if trying to play outside that range, so the signal needs to be divided into specific frequency ranges that are fed to specific drivers to deal with each range). The standard high-definition sample rates are 44.1khz and 48khz, which cover the human hearing maximum frequency of 20khz and has a little wiggle room for reconstruction filters, so most hardware doesn't bother with components for the super-high frequencies you can't hear, let alone have quality parts for them.

So, the solution seems to be changing the period size?

The period size and period count. Along with the sample-type, channels, and frequency settings, you should just leave them at the defaults since OpenAL Soft will detect the settings from the system automatically and use reasonable defaults elsewhere, making sure they all stay correct relative to each other (e.g. the period size or count may be increased if the sample rate got increased, to ensure the intended timing/latency remain roughly consistent).

[Mynameislol]

Thank you! It solved everything. I've also learned a few things, thanks!