Autogain Artifacts

[chboishabba]

Thank you very much for this incredible tool! I can't believe how easy it is compared to Equalizer APO on Windows. If I may suggest a feature (that I may eventually be able to contribute to if nobody else does, but I'm not in a great spot at the moment). That would be that some smoothing be applied to the final output gain from the AutoGain plugin. I have noticed at times, some artefacts that seem to be caused by the gain being adjusted at effectively a frequency that ends up coming through in the audio. I love the graphs that show what it's thinking about but I would love some sort of damping knob. Perhaps one could specify maximum acceleration value or something, or maybe a curve or something. If this makes any sense... at the moment the gain graph moves like insects, when I would assume it would be best as lapping waves on a beach. Thanks again for this amazing tool!

[wwmm]

I have noticed at times, some artefacts that seem to be caused by the gain being adjusted at effectively a frequency that ends up coming through in the audio. I love the graphs that show what it's thinking about but I would love some sort of damping knob. Perhaps one could specify maximum acceleration value or something, or maybe a curve or something. If this makes any sense... at the moment the gain graph moves like insects, when I would assume it would be best as lapping waves on a beach.

The gain is updated whenever PipeWire sends a new audio buffer. But I am not sure about what you want to smooth. Is it the gain value itself or just its presentation in the levelbar/label visible in the window?

If it is the gain value correction changing too fast and making the audio output volume to oscillate too fast something you may try is to change the reference to something like Geometric (SI). This mode will use the geometric mean of the short-term and integrated loudness to do the correction. The EBUR128 standard uses a time window of 3 seconds for the short-term loudness and of 400 ms for the momentary loudness. Not using the momentary loudness will make the correction to change at slower pace.

But if you are talking about just the visualization on the window that is a tougher problem to solve. Depending on the latency and sampling rate the frequency at which PipeWire sends buffers can change a lot. I have put some code in place to mitigate this and make the animation frequency more consistent but it is not perfect. In EasyEffects preferences window there is a parameter that allows the update frequency of the level meters and spectrum to be adjusted but the most it can do is making the update rate slower than the PipeWire is sending buffers. We can not make the animations update faster than this for example.

[wwmm]

I can't believe how easy it is compared to Equalizer APO on Windows

To be fair EasyEffects is entirely focused on stereo signal processing and not general purpose multichannel processing like APO. So there are some advantages in its more complex design.

[chboishabba]

No I am not referring to the animations but the rate of change for the gain. I believe I had tried the other smoothing functions and was still experiencing the issue. I will re-test and confirm.

EDIT: Tested with Geometric (SI). I don't know if it actually has anything to do with rate of adjustment; it seems to be just general audio glitching, looking at the arch wiki it seems possibly buffer underruns, the wiki seems to suggest switching timer based scheduler state according to back end https://wiki.archlinux.org/title/PulseAudio/Troubleshooting

On Thu, Jan 25, 2024, 12:37 AM Wellington Wallace @.***> wrote:

I have noticed at times, some artefacts that seem to be caused by the gain being adjusted at effectively a frequency that ends up coming through in the audio. I love the graphs that show what it's thinking about but I would love some sort of damping knob. Perhaps one could specify maximum acceleration value or something, or maybe a curve or something. If this makes any sense... at the moment the gain graph moves like insects, when I would assume it would be best as lapping waves on a beach.

The gain is updated whenever PipeWire sends a new audio buffer. But I am not sure about what you want to smooth. Is it the gain value itself or just its presentation in the levelbar/label visible in the window?

If it is the gain value correction changing too fast and making the audio output volume to oscillate too fast something you may try is to change the reference to something like Geometric (SI). This mode will use the geometric mean of the short-term and integrated loudness to do the correction. The EBUR128 standard uses a time window of 3 seconds for the short-term loudness and of 400 ms for the momentary loudness. Not using the momentary loudness will make the correction to change at slower pace.

But if you are talking about just the visualization on the window that is a tougher problem to solve. Depending on the latency and sampling rate the frequency at which PipeWire sends buffers can change a lot. I have put some code in place to mitigate this and make the animation frequency more consistent but it is not perfect. In EasyEffects preferences window there is a parameter that allows the update frequency of the level meters and spectrum to be adjusted but the most it can do is making the update rate slower than the PipeWire is sending buffers. We can not make the animations update faster than this for example.

— Reply to this email directly, view it on GitHub https://github.com/wwmm/easyeffects/issues/2866#issuecomment-1908260175, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGM4B3RSODELJNT5RS5KJVLYQEMCZAVCNFSM6AAAAABCIZKDICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBYGI3DAMJXGU . You are receiving this because you authored the thread.Message ID: @.***>

[wwmm]

the wiki seems to suggest switching timer based scheduler state according to back end

Timer based scheduling was more problematic in Pulseaudio early days. And in the cases where the driver does not support it well Pulseaudio/PipeWire already has no other option other than using interrupt based scheduling. The drivers for the first generations of ryzen motherboard had the timer based scheduling disabled for example.

There are many things that could cause "general audio glitching" but based on what is usually reported to me the first thing I would try is forcing PipeWire to temporarily use a fixed latency and see if this changes anything. Try to set a fixed power of 2 based quantum value like 1024 or 2048 for some time.

Most plugins in EasyEffects handle PipeWire's dynamic latency switching but the convolver and the crystalizer don't. I do not hear glitches on my hardware but some users hear on them when the latency changes on the fly. Maybe that is what you are listening to if you use any of these plugins together with the autogain.

[chboishabba]

Adjusting per the guide seems to have alleviated the problem through short term testing. I used GPT to calculate sample rate processing ms indicated in pipewire bottom left. Indicated latency was 105ms, adjusted buffer to 6000 (5040 calculated). It seems this would be a useful variable to be adjusted in preferences, perhaps with a suggested buffer based on (msrate)+error. Thanks for your solution.

On Sun, Jan 28, 2024 at 2:19 PM Wellington Wallace @.***> wrote:

the wiki seems to suggest switching timer based scheduler state according to back end

Timer based scheduling was more problematic in Pulseaudio early days. And in the cases where the driver does not support it well Pulseaudio/PipeWire already has no other option other than using interrupt based scheduling. The drivers for the first generations of ryzen motherboard had the timer based scheduling disabled for example.

There are many things that could cause "general audio glitching" but based on what is usually reported to me the first thing I would try is forcing PipeWire to temporarily use a fixed latency https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Guide-Latency and see if this changes anything. Try to set a fixed power of 2 based quantum value like 1024 or 2048 for some time.

Most plugins in EasyEffects handle PipeWire's dynamic latency switching but the convolver and the crystalizer don't. I do not hear glitches on my hardware but some users hear on them when the latency changes on the fly. Maybe that is what you are listening to if you use any of these plugins together with the autogain.

— Reply to this email directly, view it on GitHub https://github.com/wwmm/easyeffects/issues/2866#issuecomment-1913612619, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGM4B3VKKHEH44CTE7XWUSTYQZM73AVCNFSM6AAAAABCIZKDICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTGYYTENRRHE . You are receiving this because you authored the thread.Message ID: @.***>

[chboishabba]

Effects enabled are: Loudness, Compressor, Autogain Geometric (SI), Crossfeed.

On Sun, Jan 28, 2024 at 2:19 PM Wellington Wallace @.***> wrote:

the wiki seems to suggest switching timer based scheduler state according to back end

Timer based scheduling was more problematic in Pulseaudio early days. And in the cases where the driver does not support it well Pulseaudio/PipeWire already has no other option other than using interrupt based scheduling. The drivers for the first generations of ryzen motherboard had the timer based scheduling disabled for example.

There are many things that could cause "general audio glitching" but based on what is usually reported to me the first thing I would try is forcing PipeWire to temporarily use a fixed latency https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Guide-Latency and see if this changes anything. Try to set a fixed power of 2 based quantum value like 1024 or 2048 for some time.

Most plugins in EasyEffects handle PipeWire's dynamic latency switching but the convolver and the crystalizer don't. I do not hear glitches on my hardware but some users hear on them when the latency changes on the fly. Maybe that is what you are listening to if you use any of these plugins together with the autogain.

— Reply to this email directly, view it on GitHub https://github.com/wwmm/easyeffects/issues/2866#issuecomment-1913612619, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGM4B3VKKHEH44CTE7XWUSTYQZM73AVCNFSM6AAAAABCIZKDICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTGYYTENRRHE . You are receiving this because you authored the thread.Message ID: @.***>

[chboishabba]

System: i7 7700k @ 4.5, 32gb 3000, Focusrite 2i2

On Sun, Jan 28, 2024 at 2:19 PM Wellington Wallace @.***> wrote:

the wiki seems to suggest switching timer based scheduler state according to back end

Timer based scheduling was more problematic in Pulseaudio early days. And in the cases where the driver does not support it well Pulseaudio/PipeWire already has no other option other than using interrupt based scheduling. The drivers for the first generations of ryzen motherboard had the timer based scheduling disabled for example.

There are many things that could cause "general audio glitching" but based on what is usually reported to me the first thing I would try is forcing PipeWire to temporarily use a fixed latency https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Guide-Latency and see if this changes anything. Try to set a fixed power of 2 based quantum value like 1024 or 2048 for some time.

Most plugins in EasyEffects handle PipeWire's dynamic latency switching but the convolver and the crystalizer don't. I do not hear glitches on my hardware but some users hear on them when the latency changes on the fly. Maybe that is what you are listening to if you use any of these plugins together with the autogain.

— Reply to this email directly, view it on GitHub https://github.com/wwmm/easyeffects/issues/2866#issuecomment-1913612619, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGM4B3VKKHEH44CTE7XWUSTYQZM73AVCNFSM6AAAAABCIZKDICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTGYYTENRRHE . You are receiving this because you authored the thread.Message ID: @.***>

[wwmm]

Effects enabled are: Loudness, Compressor, Autogain Geometric (SI), Crossfeed.

These plugins are able to handle the dynamic latency switching. So whatever the glitch was it seems to be starting on the server/driver side when the latency is too low for the system to handle.

It seems this would be a useful variable to be adjusted in preferences, perhaps with a suggested buffer based on (ms*rate)+error. Thanks for your solution.

Ideally PipeWire's dynamic latency switching should just work. It is a nice feature to have because having too low latency all the time wastes CPU power. But having it too high can cause lag or out of sync video in some situations. So having the latency adjusted dynamically to a low enough value is a good thing. The problem is when the hardware/driver does not play nice with what PipeWire is trying to achieve.