[1.0.0] Audio issue when Windows audio sample rate set above 352.8KHz

[El_Maximo_Bango]

In Windows 10 when the audio device's sample rate is set to 352.8KHz and above, the game gives an error at startup on the main menu stating "Audio Error. Could not initialize audio. Audio is disabled."

Any sample rate lower than 352.8KHz works fine and does not error.

I am using an external DAC, the Topping E30.

[BTWhite]

I have a Topping D10s and have the same issue. I downgraded to 192k and did not get the error. Running version 1.1.19 (build 57957, win64)

[bohndiggin]

I have the same issue. It's driving me crazy lol.

[Rseding91]

Unless another developer wants to go looking into it I'm fine with saying that we only support 24 bit, 48000 Hz audio and if anything else works that's fine but we won't be looking into bug reports/issues around audio outside that setting.

[Donion]

More out of curiosity than anything else, does changing the audio backend to sdl behave differently, as in this similar topic viewtopic.php?p=566986#p566986 ?

I have no practical way of troubleshooting theses issues at the moment so I would agree with Rseding, with anything above 24b 48kHz (32b should be fine too) there are no guarantees.

[ptx0]

for the record. using anything higher than 40KHz (for games or day-to-day desktop use) is pointless. the frequency should be at most, twice the highest frequency in the media played back. and humans can only hear up to 20kHz when youthful and fresh. we lose this as we grow older.

in other words, for a mature adult, 32KHz audio is likely good enough and you won't notice any difference, unless you have exceptional hearing.

what does happen is the sound driver must send audio to the device at that rate. that is why it is called the sample rate. you're going to be burning CPU just sending frames of audio to the device when the played audio doesn't even have the available resolution.

in other words, you're trying to play 44.1KHz or 48kHz audio through a 352kHz interface. this means that the audio becomes linearly interpolated, and this is unnatural. you want all of the system hardware to use the same sample rate, otherwise you've got upmixing overhead and artifacting due to the interpolation.

bottom line is, you need to change your audio device to 48KHz or 44.1KHz inside the sound device properties inside Windows.

[El_Maximo_Bango]

More out of curiosity than anything else, does changing the audio backend to sdl behave differently, as in this similar topic viewtopic.php?p=566986#p566986 ?

I have no practical way of troubleshooting theses issues at the moment so I would agree with Rseding, with anything above 24b 48kHz (32b should be fine too) there are no guarantees.

Sorry for the late reply, I had forgotten all about this post.

As it turns out a driver update for my resolved this issue. I have no problems with audio in Factorio with any setting I set since updating the driver.

[El_Maximo_Bango]

for the record. using anything higher than 40KHz (for games or day-to-day desktop use) is pointless. the frequency should be at most, twice the highest frequency in the media played back. and humans can only hear up to 20kHz when youthful and fresh. we lose this as we grow older.

in other words, for a mature adult, 32KHz audio is likely good enough and you won't notice any difference, unless you have exceptional hearing.

what does happen is the sound driver must send audio to the device at that rate. that is why it is called the sample rate. you're going to be burning CPU just sending frames of audio to the device when the played audio doesn't even have the available resolution.

in other words, you're trying to play 44.1KHz or 48kHz audio through a 352kHz interface. this means that the audio becomes linearly interpolated, and this is unnatural. you want all of the system hardware to use the same sample rate, otherwise you've got upmixing overhead and artifacting due to the interpolation.

bottom line is, you need to change your audio device to 48KHz or 44.1KHz inside the sound device properties inside Windows.

That makes sense, thanks for the advice. Matching the sample rate of the source sounds like obvious way to go there.