-
Notifications
You must be signed in to change notification settings - Fork 793
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crackling sound with 1.2.0 and 1.4.0 #1390
Comments
Strange, I don't think we changed how the audio in the videos is handled (it was streaming in 1.1.0 as well) |
Ah but we did change how the volume is handled for videos |
@glebm So maybe it's clipping? |
Can you try reducing your volume in the in-game settings to see if the issue disappears? |
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 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 |
@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. |
The audio issue should now be fixed, could you test the latest beta: |
I'm not able to reproduce the audio problem with the latest beta Edit: Removed erroneous information. |
upload on github, don't use some fishy hostings :S |
@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? |
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. |
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 think it's a bug with SDL's integration with the default windows resampler |
We had a workaround for this where we used another windows audio api by default but that was removed at some point |
Specifically it was removed for 1.4.0 |
I did some testing: 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. |
Sounds wrong since we do not use SDL for resampling, |
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. |
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.
This is a recommendation from Speex documentation, which is the software resampler we use with SDL_audiolib.
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. |
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 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. |
I agree, the effect of this is not as big as the clipping or even latency.
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.
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. |
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. |
Some observations: Edit: sorry, uploaded the wrong video for 3, now it is correct. |
This is with the newest resampler after #4457 |
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 |
I wonder if this is an artifact of the source sound clips not being cut at a zero point in the wave form. |
The first part of that sound is actually non properly zeroed: |
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) |
@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: 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. |
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.
22500 would likely cause issues, please try 22050 instead. |
@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) |
It's a Micca Origen+. |
Interesting that it's another USB DAC thing. Does 1.2.1 behave like 1.3.0? |
No, it behaves like 1.2.0. I don't think resampling is available on 1.2.0/1.2.1, is it? |
Resampling is indeed not available in 1.2.1. It was hardcoded to 22050. Line 172 in 3e61cb8
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. |
@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. |
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.
The text was updated successfully, but these errors were encountered: