4.5.0 Audio "pops" again

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: 4.5.0 Audio "pops" again

Re: 4.5.0 Audio "pops" again

by Chris » Thu Feb 04, 2021 3:00 pm

Graf Zahl wrote:Good to hear. Unless a new official release happens I'm going to put this DLL into the next releases then.
1.21.1 was just released (Windows bins: https://openal-soft.org/openal-binaries ... .1-bin.zip).

Re: 4.5.0 Audio "pops" again

by Chris » Fri Jan 29, 2021 12:36 pm

_mental_ wrote:Chris, please post commit that fixes the issue.
Commit f0f7bc03.

Re: 4.5.0 Audio "pops" again

by _mental_ » Fri Jan 29, 2021 1:13 am

Chris, please post commit that fixes the issue.

Re: 4.5.0 Audio "pops" again

by Graf Zahl » Thu Jan 28, 2021 4:06 pm

Good to hear. Unless a new official release happens I'm going to put this DLL into the next releases then.

Re: 4.5.0 Audio "pops" again

by Enjay » Thu Jan 28, 2021 3:55 pm

Just a quick update - I know that it's only been a couple of days, but I have done a lot of Dooming (+Hereticing, Hexening, Strifing) - standard games and modded - in that time and I have been using the above openal32.dll throughout. I have used it with 4.5.0 and I have used it with git builds, including the one that was posted today.

I have not noticed any problems with the new dll during this time (no idea why that hang happened the first time that I used it, but there has been no recurrence) and I have not noticed any popping of the type that this thread was started about.

In other words, it seems to address the original issue and does not seem to have created any problems elsewhere.

Re: 4.5.0 Audio "pops" again

by Enjay » Tue Jan 26, 2021 10:34 am

On a quick test using the example file from this thread, it's much better. I don't detect any pops and I have now run up that corridor several times in 4.5.0 official and a git build using the OpenAL32.dll that you just posted. So, it seems to have addressed the issue I started the thread about and I'll keep it in my GZDoom directory and report if anything untoward happens with it.

The one thing worth mentioning: when I first dropped the new dll into my 4.5.0 GZDoom folder, GZDoom hung on "setting up sound system" and I had to exit the program (it was still just showing the little startup console box and I pressed the X to quit). It has worked every subsequent time though (at least 10 times) and it did not happen when I tried it with the git build.

Re: 4.5.0 Audio "pops" again

by Chris » Tue Jan 26, 2021 8:15 am

How well does the attached OpenAL dll work at preventing the popping? It seems to be working here, but I'd like to make sure before committing to it. Also, if you start experiencing clicks or pops with other sounds that end prematurely, it would be helpful to know with what.

(Reposted since I spotted an error in the old upload)
Attachments
OpenAL32.zip
(709.46 KiB) Downloaded 32 times

Re: 4.5.0 Audio "pops" again

by Enjay » Sat Jan 02, 2021 1:24 pm

Chris wrote:I suppose it would be more correct to say "OpenAL's handling of the issue was considered suitable". With all my testing and feedback I got from others with various OpenAL apps, the problem of clicks/pops with sounds being preempted seemed to go away, and prior to now, I haven't seen an issue where it fails. If there's still any clicks/pops from sounds stopping mid-playback, it's a problem with OpenAL.
Understood. Thanks for the clarification.
Chris wrote:Functionally speaking, no. It won't have any click prevention, so any instances where it was more effective may start popping more, but GZDoom should run fine with it.
I'll run with the older dll for my regular playing for the time being then. It's a much more pleasant experience with the WADs I've been playing and I haven't noticed any issues along the lines you describe yet.
Chris wrote:I don't think that particular case is. I'm seeing a bit of weirdness in the beginning of the 4.5 waveform, and the timing isn't the same with the 4.3 waveform so I can't do a more direct comparison, but it looks like 4.3 isn't preempting the UI sounds as aggressively.
Fair enough. As I said, it could have just been my imagination anyway.

Re: 4.5.0 Audio "pops" again

by SanyaWaffles » Sat Jan 02, 2021 1:13 am

So the music and sounds are independent code-wise? That's good to know.

Okay. I'll open up a separate issue again once I can figure out a good way to test and make sure the issue. I don't want to plague this thread with stuff unrelated.

Re: 4.5.0 Audio "pops" again

by Chris » Fri Jan 01, 2021 11:48 pm

Enjay wrote:I notice that you said that "OpenAL's handling of the issue was suitable" but obviously a problem still exists somewhere because popping like I'm getting is clearly a problem. So if OpenAL is now doing something suitable, does the problem lie within GZDoom and how it uses OpenAL now?
I suppose it would be more correct to say "OpenAL's handling of the issue was considered suitable". With all my testing and feedback I got from others with various OpenAL apps, the problem of clicks/pops with sounds being preempted seemed to go away, and prior to now, I haven't seen an issue where it fails. If there's still any clicks/pops from sounds stopping mid-playback, it's a problem with OpenAL.
Enjay wrote:With the "bookkeeping" gone in 4.5.0, is there any harm in (temporarily) using the openal32.dll from 4.3.3?
Functionally speaking, no. It won't have any click prevention, so any instances where it was more effective may start popping more, but GZDoom should run fine with it.
SanyaWaffles wrote:One thing of interest it is affects both music and sound in a similar fashion.
This has nothing to do with music, it's purely about sound sources that stop mid-playback. Your problem with music looping would always have been a problem because the behavior with looping hasn't changed (a looping sound plays a continuous streams of samples while the reader seeks back to the loop start when it reaches the loop end, without ever stopping). Maybe a bug got introduced with music looping when zmusic got split into an external library, perhaps, but that would be a separate issue independent of OpenAL.
Enjay wrote:In fact, if you listen back to my example WAVs files, I started the game by opening the menu and then just hitting enter twice. You can hear the menu opening sound in both samples, and then two pistol shots that played when the menu entries were chosen. In both cases, the second pistol shot gets clipped, but the 4.5.0 one gets clipped much more quickly. Could that also be down to this change?
I don't think that particular case is. I'm seeing a bit of weirdness in the beginning of the 4.5 waveform, and the timing isn't the same with the 4.3 waveform so I can't do a more direct comparison, but it looks like 4.3 isn't preempting the UI sounds as aggressively.

Re: 4.5.0 Audio "pops" again

by Enjay » Fri Jan 01, 2021 6:52 pm

This could just be my imagination but thinking about Chris' explanation, I've had a funny feeling recently that sometimes certain sounds seem to be clipped more abruptly that they used to be. I'm quite happy for someone to just put it down to me imagining things but some sounds, such as the sound of a switch that ends the level just seemed to be stopping more quickly and more sharply than they did before.

In fact, if you listen back to my example WAVs files, I started the game by opening the menu and then just hitting enter twice. You can hear the menu opening sound in both samples, and then two pistol shots that played when the menu entries were chosen. In both cases, the second pistol shot gets clipped, but the 4.5.0 one gets clipped much more quickly. Could that also be down to this change?

Re: 4.5.0 Audio "pops" again

by SanyaWaffles » Fri Jan 01, 2021 6:30 pm

One thing of interest it is affects both music and sound in a similar fashion.

I can't exactly test SHDX with 4.3.3 because it uses ZScript functionality to see if the music problem goes away.

I am in agreement with Enjay, something is definitely wrong here.

Re: 4.5.0 Audio "pops" again

by Enjay » Fri Jan 01, 2021 5:45 pm

I'm basically following what you are saying there, but it's certainly not my area of expertise, so I may have missed something important.

I notice that you said that "OpenAL's handling of the issue was suitable" but obviously a problem still exists somewhere because popping like I'm getting is clearly a problem. So if OpenAL is now doing something suitable, does the problem lie within GZDoom and how it uses OpenAL now?

With the "bookkeeping" gone in 4.5.0, is there any harm in (temporarily) using the openal32.dll from 4.3.3? The popping is happening so often with 4.5.0 (and right up to today's git build) in the maps that I have been playing that it has become very annoying. Maps with rows of bonuses to collect are borderline unplayable to my ear. So, I'll happily use the old dll as a stop-gap (rather than fall back to an older version of GZDoom entirely).

Re: 4.5.0 Audio "pops" again

by Chris » Fri Jan 01, 2021 4:36 pm

To clarify what seems to be going on, what's happening is the armor pickup sound plays on the local channel for player pickup sounds. When you pick up another armor bonus, it stops the current pickup sound and starts playing it again (since only one instance of that sound is allowed to play at a time). The faster you pick them up, the sooner they get cut off. If a sound just stopped mixing without any consideration for anything, there could be a significant amplitude change since it now would essentially be mixing 0s compared to what it was just before it stopped.

In older versions of GZDoom (4.3.3), this was worked around by making it so when a sound is supposed to stop, the sound source would instead continue playing but its gain would be set to 0. That would make OpenAL fade the sound to silence over the course of the next mixing update while it kept playing (meanwhile, the sound source would be unusable for playing another sound and the sound buffer would remain in use). GZDoom would wait for a few frames before stopping the sound source for real. Consequently, GZDoom had to keep track of "stopped" sound sources, wait until OpenAL mixed and silenced them by checking the current time vs when they were set to silence, then actually stop them. And if a sound buffer needed to be removed from the cache, it had to be more careful to ensure "stopped" sources were really stopped (potentially causing a click/pop anyway) so the sound buffer could be deleted.

While this worked, it resulted in increased bookkeeping costs on GZDoom's side, and it only benefited GZDoom (there was also the limitation that it did nothing for sounds being paused, so things like opening/closing the menu or console could still cause clicks/pops). Having a built-in solution that would work for all OpenAL apps and regardless of why a sound stopped mixing would be much more desirable since apps then wouldn't have to care and would get glitch/pop-free playback regardless. So with OpenAL Soft 1.20, I implemented the method that is being used now (when a sound is stopped, the internal mixing voice is set to do one more mix without any associated sound source or sound buffer, since the app may be changing or deleting them, using the last known sample values to fade to silence). Later versions of GZDoom that updated to OpenAL Soft 1.20 removed the extra bookkeeping code since OpenAL's handling of the issue was suitable.

Re: 4.5.0 Audio "pops" again

by Nash » Fri Jan 01, 2021 3:10 pm

Chris wrote:It almost looks like OpenAL Soft's click/pop prevention isn't working as well as it should. I mean, it seems to be doing exactly what it should -- I can see in the 4.5 waveform where the sound stops mixing at the start of an update, and then slowly fades the DC offset back to 0 over the update (rather than immediately snapping to 0, which as noted in the other thread, would just as well cause clicks/pops). I don't know if the still-audible pops are a limitation of the method, or if the fade should be more logarithmic instead of linear, or whether it's acting too fast or too slow, or something else unrelated that the old version just hides better.

It doesn't seem to be so bad for me, though. When I run your test map, if I listen closely I can make out a small bit of popping sometimes, which is consistent with all my testing thus far; in GZDoom and other OpenAL apps, clicks/pops from sounds being stopped are all but gone, unless I listen really closely I can sometimes hear it a little. But I do hear it more pronounced in your recordings, for some reason.

Chris: the pop is louder when the player moves faster (in Enjay's map - moving faster means you pick up more of the armor bonuses in a shorter amount of time, increasing the probability for the clicks to happen because they sounds are playing so
close to each other)

Top