Crackling sound with 1.2.0 and 1.4.0

[malvarenga123]

Important information
Windows 7 x64
DevilutionX 1.2.0 x64 downloaded from releases

Describe
As soon as the opening Blizzard video starts, there's a lot of crackling static.
In a game, if I just stay in town doing nothing, eventually the music will have some crackling too.
My CPU/HDD are almost idle during the issue.
If I run 1.1.0, the sound is perfect.

Expected behavior
Not have crackling sounds.

Additional context
I'm guessing it has to do with streaming the files instead of loading all of them into memory, which we already discussed. I did expect something like this with a very intense use of the disk or CPU, but not when they were almost idle.

[glebm]

Strange, I don't think we changed how the audio in the videos is handled (it was streaming in 1.1.0 as well)

[glebm]

Ah but we did change how the volume is handled for videos

[malvarenga123]

@glebm So maybe it's clipping?

[glebm]

Can you try reducing your volume in the in-game settings to see if the issue disappears?
The in-game audio settings apply to videos in 1.2.0

[AJenbo]

Was running the game from my original CD today and didn't have with this, so don't think it's an I/O problem.

Can you try the 32bit version since 1.1.0 was only available in 32bit for Windows.

[malvarenga123]

@glebm I tried reducing the audio volume to half and the issue persisted. Even editing the .ini to -1000 or -1200 didn't help.

@AJenbo same issue with x86 build.

[AJenbo]

@malvarenga123 are you able to get a recording of this, is it only music or also regular sounds (not dialogs).

Is it similar to what is seen in this stream at 4:00:08
https://www.twitch.tv/videos/977773450

[malvarenga123]

@AJenbo I'm going to close this one for now because I'm not able to reproduce it consistently enough to record the audio at least. If/when I'm able to do it, I'll open a new issue.

It's really strange though, yesterday I was able to repeatedly get the crackling sound. Today, after you asked me to record it, it seems to be gone.

Answering your question, it wasn't like the issue in the video.

[AJenbo]

The audio issue should now be fixed, could you test the latest beta:
https://27487-143324737-gh.circle-artifacts.com/0/devilutionx_x64.zip

[malvarenga123]

I'm not able to reproduce the audio problem with the latest beta

Edit: Removed erroneous information.

[qndel]

upload on github, don't use some fishy hostings :S

[glebm]

@malvarenga123 I hear no issue with the music in the audio you've uploaded (also had @julealgon listen to it just to be sure). What do you hear?

[malvarenga123]

I'm sorry, there was an issue with my speakers cutting off some sounds when I recorded this.

There is no problem with the music.

[malvarenga123]

Hey @glebm, I haven't been playing for a while and decided to try the 1.4.0 release. The crackling sound issue immediately showed up on the opening movie and for all songs.
I looked at the ini and noticed that the default sample rate was 22050 and buffer size 2048. I changed the sample rate to 96000 (which is what I use as the default output) and increased the buffer size to 20480. Now, there's no issue and audio plays perfectly.

[glebm]

I think it's a bug with SDL's integration with the default windows resampler
By setting a matching sample rate, you bypass the windows resampler, working around the issue.
There's no need to change the buffer size

[glebm]

We had a workaround for this where we used another windows audio api by default but that was removed at some point

[AJenbo]

Specifically it was removed for 1.4.0

[ikonomov]

I did some testing:
22050 (resampling quality and buffer should be ignored) : still has the same problem as before, lots of clipping, except it's even worse than the last time we tested this. This is likely the case setting the sampling rate to anything other than the default for Windows.

48000 (resampling quality 0 or 3, buffer 1024 or 4096): default sampling rate in Windows and what I have it set to, there is no clipping, as the resampling is done by the SDL. The ideal resampling quality and buffer size will vary from system to system, but on my system (2 years old CPU), resampling quality of anything other than 0 results in some sound quality artifacts. This is not clipping, and it happens both at buffer 1024 and 4096 which tells me that it is probably a problem by the resampling algorithm even though I remember staphen found somewhere in the SDL's documentation a recommendation of a minimum resampling quality of 3. This can be heard by picking up an item in the inventory. For me both 1024 and 4096 result in no difference other than the increased sound latency. 22050 is quite rare nowadays, with lossy compression there is just no reason cut audio above 11KHz, so it is possible that this issue could be something specific to this low sound rate with the SDL resampler and their recommendation of 3 might not be ideal here.

If we don't have a choice with the SDL library and this is the best or only option for us, I think if possible we should look for ways to have the game read Windows' default sampling rate and set the game's output to it. If that's not possible I think we should set it to 48000 at least for Windows, as that's the default when you install the last few versions of Windows. The buffer size of 2048 that we have now is I think too far on the conservative side for a computer, so I think if we do here another check for the OS it can be safely lowered to 1024. Maybe we can have a few people with lower end CPUs do some testing to confirm if 1024 is ok, if there are issues with the buffer it should be very easy to hear.

[AJenbo]

I remember staphen found somewhere in the SDL's documentation a recommendation of a minimum resampling quality of 3.

Sounds wrong since we do not use SDL for resampling,

[AJenbo]

Personally I feel like we should revert #4023 and go back to using WINMM on Windows since WASAPI apparently is hit an miss.

@ikonomov I'm surprised that you haven't noticed this since you seam to have played the betas a lot over the past several months since the audio path was touched. It would be good if you could look in to when things changed for the worse on your system. Since you are the only one really complaining about this I can't really tell if it's something specific with your system or not.

[StephenCWills]

The ideal resampling quality and buffer size will vary from system to system, but on my system (2 years old CPU), resampling quality of anything other than 0 results in some sound quality artifacts.

Resampling quality is likely a matter of personal preference. If it doesn't sound different when you change the number, then something is wrong because the whole point is to change the way it sounds. From what I recall, the artifacts you hear at higher quality settings are more pronounced with specific sound clips and are likely due to the resampler boosting contrast between frequencies in those audio clips. In other words, it's probably just noise in the original recording that was amplified by the resampler.

The fact that the original recording has noise that is boosted by the resampler might be reason enough to lower the resampling quality, but to my ears the effect is so miniscule at the recommended quality setting of 3 that I don't feel compelled to go against the recommendation.

... even though I remember staphen found somewhere in the SDL's documentation a recommendation of a minimum resampling quality of 3.

This is a recommendation from Speex documentation, which is the software resampler we use with SDL_audiolib.

Personally I feel like we should revert #4023 and go back to using WINMM on Windows since WASAPI apparently is hit an miss.

FYI, @ikonomov reported high audio latency with winmm when we decided to switch back to the default. I can reproduce the high latency, but I can't reproduce the crackling with WASAPI. However, I'm inclined to agree. If I had to choose between high latency and crackling, I'd go with high latency in a heartbeat.

[ikonomov]

Sounds wrong since we do not use SDL for resampling,

I remember a discussion about it, maybe it is Speex. Whatever we are currently using, it is not doing a good job at resampling quality of 3 on Windows. Maybe quality of 3 sounds good on other systems, so that's why I'm advocating to do a check for the OS.

I'm surprised that you haven't noticed this since you seam to have played the betas a lot over the past several months since the audio path was touched.

I have my .ini set to 48000 (same rate as in Windows) and resampling quality of 0. This is the reason why I haven't noticed.

[ikonomov]

The fact that the original recording has noise that is boosted by the resampler might be reason enough to lower the resampling quality, but to my ears the effect is so miniscule at the recommended quality setting of 3 that I don't feel compelled to go against the recommendation.

I agree, the effect of this is not as big as the clipping or even latency.

If I had to choose between high latency and crackling, I'd go with high latency in a heartbeat.

I also agree with this as well. I think clipping (crackling) should take the biggest priority to avoid, followed by latency (as this is a game) and lastly the small artifacts that I hear at the recommended resampling quality between 3 and 0 maybe could be ignored. I'm almost tempted to do some recordings to test this, but using the recommendation has some merit considering possible future updates to the resampler.

WINMM on Windows

MME driver in Windows is not suited for a game like Diablo in my opinion, as far as I know no type of game like this uses it because of the increased latency.

[AJenbo]

Sounds wrong since we do not use SDL for resampling,

I remember a discussion about it, maybe it is Speex. Whatever we are currently using, it is not doing a good job at resampling quality of 3 on Windows. Maybe quality of 3 sounds good on other systems, so that's why I'm advocating to do a check for the OS.

This has nothing to do with OS. I think you are confusing several layers with each other.

See if you can record this, either on the system, or with a different system grabing the input of the system that is producing the "bad" sound. Also record it from a version that produces what you feel is good sound. Then lets compare histograms and see what is actually going on.

[ikonomov]

1. Speex resampler, 48000 sample rate (same as Windows), quality 3:
   https://user-images.githubusercontent.com/5624187/163591911-530fa5a3-999f-4e36-aa3b-338237217802.mp4
   

2. 22050 resample rate, same as the source .wav so should be handled by WASAPI:
   https://user-images.githubusercontent.com/5624187/163592237-008802be-88c2-4b22-bf23-28fbc6f72cd0.mp4
   

3. Speex resampler, 48000 sample rate (same as Windows), quality 0:
   https://user-images.githubusercontent.com/5624187/163594877-97aec6f1-3f74-4dc5-9960-4c027642649a.mp4
   

Some observations:
22050 is like the source material, because the Speex resampler is by-passed on the recording it should be as if we are looking at the frequency graphs of the source.
The vertical bars at 48000 q3 is those added artifacts that seem to change in nature at different quality levels. At quality 0 they are gone, but we have the artificially added noise above 11k which cannot exist at 22050 sample rate, and also a bit closer we can see that the actual sound has been changed which we can assume is due to the poor resampling algorithm adding noise throughout the whole spectrum.

Edit: sorry, uploaded the wrong video for 3, now it is correct.

[ikonomov]

This is with the newest resampler after #4457
Sampling rate inside the ini set to 48000, matching windows's sampling rate:
https://user-images.githubusercontent.com/5624187/163659610-6d66cce4-f0f8-4fda-95ee-250171296f3a.mp4

[ikonomov]

Because there is an issue with crackling with my RME Babyface WASAPI driver that can be seen in the example (2) above represented by a few vertical bars, just for reference, I'm uploading another recording at 22050Hz sample rate, this time with the motherboard built-in audio device.

Desktop.2022.04.16.-.10.49.39.04.mp4

[AJenbo]

I wonder if this is an artifact of the source sound clips not being cut at a zero point in the wave form.

[AJenbo]

The first part of that sound is actually non properly zeroed:

@ikonomov can you see what happens if you edit the file to mute the first 0.006 sec of it?

[qndel]

Okay time for me to pitch in :D For me 48khz produces crackling sound in menu, same with 44100, only 22050 hz is fine. (noticed after deleting my config and default one sounds like poo at the moment)

[malvarenga123]

@AJenbo as I mentioned a while ago. The crackling sound problem always occurred randomly for me since 1.2.0. Basically this is what I was able to notice:
1.1.0: no issues ever.
1.2.0: crackling sound randomly. It has to happen on Blizzard's opening video (and during songs) or not at all.
1.3.0: crackling sound on all sample rates, except 22500. 100% reproducible.
1.4.0: crackling sound randomly (rare) on sample rates different from the sound card's default (my case it was 96000). Same thing as 1.2.0, it happens during Blizzard's opening video or not at all.

I tried replacing SDL's dll with the one from 1.1.0 and it only worked with 1.2.0. I wasn't able to reproduce the issue, but considering it occurs randomly, I can't be 100% sure it was solved.

[AJenbo]

I tried replacing SDL's dll with the one from 1.1.0 and it only worked with 1.2.0.

Is this because of miss matched 32bit and 64bit versions? Make sure to use the 32bit versions. Can you also please let us know what version of the DLL comes with 1.1.0.

1.3.0: crackling sound on all sample rates, except 22500. 100% reproducible.

22500 would likely cause issues, please try 22050 instead.

[malvarenga123]

Is this because of miss matched 32bit and 64bit versions? Make sure to use the 32bit versions. Can you also please let us know what version of the DLL comes with 1.1.0.

I was always using 32-bit. 1.3.0 and 1.4.0 show this error when you try to load 1.1.0 dll:

Its version is 2.0.12.0.

22500 would likely cause issues, please try 22050 instead.

On 1.3.0:
22050: Sound OK
44100: Crackling sound
48000: Crackling sound
96000: Crackling sound

On 1.4.0, I've had no issues with 96000 so far.

[AJenbo]

@malvarenga123 could you let us know what soundcard and driver you have (@ikonomov discovered that it was an issue specific to the one he had)

[malvarenga123]

It's a Micca Origen+.

Sadly they don't offer any updates to the driver.

[AJenbo]

Interesting that it's another USB DAC thing.

Does 1.2.1 behave like 1.3.0?

[malvarenga123]

No, it behaves like 1.2.0. I don't think resampling is available on 1.2.0/1.2.1, is it?

[StephenCWills]

Resampling is indeed not available in 1.2.1. It was hardcoded to 22050.

devilutionX/SourceX/sound.cpp

Line 172 in 3e61cb8

int result = Mix_OpenAudio(22050, AUDIO_S16LSB, 2, 1024);

However, 1.2.1 and 1.3.0 are the versions that used the MME driver. We switched back to WASAPI in 1.4.0. So probably the question here is whether you hear any crackling in 1.2.0/1.4.0 as compared to 1.2.1/1.3.0 when using 22050 as the sampling rate.

[malvarenga123]

@StephenCWills yes, it happens with 1.2.0 and 1.4.0 but it's too random to properly debug. Luckily, with 1.4.0+ resampling to the sound card's default frequency solves it for me. As for the cut off sounds, it seems that it's already being taken care of. So feel free to close this issue as it has an updated solution.