search

wwmm / easyeffects

Limiter, compressor, convolver, equalizer and auto volume and many other plugins for PipeWire applications
GNU General Public License v3.0
6.56k stars 270 forks source link

"Update Interval" Setting has no effect on Spectrum anymore #3380

Open indivisualvj opened 1 month ago

indivisualvj commented 1 month ago

EasyEffects Version

7.1.9

What package are you using?

Flatpak (Flathub)

Distribution

Linux Mint 21.2 Cinnamon

Describe the bug

Update Interval setting is described to apply to Level Meters and Spectrum, but Spectrum is (since the performance update) not rendering according to the interval i set (33ms). When i set it to 1000ms Level Meters do update once a second, but Spectrum remains in 60FPS.

Expected Behavior

Either spectrum to render according to set value or label of setting to not mention Spectrum anymore image

Also i still don't understand why this value is to be defined in Milliseconds instead of FPS or Hz.

Debug Log

No response

Additional Information

No response

wwmm commented 1 month ago

Also i still don't understand why this value is to be defined in Milliseconds instead of FPS or Hz.

It is closer to what is actually being done. That control is adding a delay between updates and not enforcing a particular fps value. Depending on the situation this isn't even possible. For example we can not update the spectrum faster than the rate PipeWire sends audio buffers.

In any case the latest changes to the spectrum made this control useless to it. We will have to address this issue in the future.

AlexFolland commented 3 weeks ago

For example we can not update the spectrum faster than the rate PipeWire sends audio buffers.

I also encountered the reported issue, and read this ticket. I noticed that this claim seems incorrect, since it's possible to process the buffered audio itself. For example, PipeWire could send 10 seconds of audio and the spectrum animation could still update at 240 Hz (or whatever the display's refresh rate is; mine is 240 Hz and I was wondering why it was updating so slowly) by processing segments of audio within that buffer, with each newly-processed segment starting 1/240 of a second further along the buffer. If the buffer is not as long as the desired segment, the segment the spectrum processes could be the last desired processing duration of the available buffer to always be able to display a processed video frame for each display refresh.

That being said, I'm not claiming that's what's happening right now or that that would be how to fix the issue. I just wanted to refute the claim that it's not possible, since it is.

wwmm commented 3 weeks ago

For example we can not update the spectrum faster than the rate PipeWire sends audio buffers.

I also encountered the reported issue, and read this ticket. I noticed that this claim seems incorrect, since it's possible to process the buffered audio itself. For example, PipeWire could send 10 seconds of audio and the spectrum animation could still update at 240 Hz (or whatever the display's refresh rate is; mine is 240 Hz and I was wondering why it was updating so slowly) by processing segments of audio within that buffer, with each newly-processed segment starting 1/240 of a second further along the buffer. If the buffer is not as long as the desired segment, the segment the spectrum processes could be the last desired processing duration of the available buffer to always be able to display a processed video frame for each display refresh.

That being said, I'm not claiming that's what's happening right now or that that would be how to fix the issue. I just wanted to refute the claim that it's not possible, since it is.

That is not how things work @AlexFolland. There is a rate at which pipewire sends audio buffers. If you try to go faster than that you do not have new data to work on. It does not matter if you are trying to work with small slices. Your idea would just draw the same set of data if you call the drawing functions between each buffer arrival.

The current code already process some of the past data together with the new buffer. The thing is the buffers are nowhere near as big as you are imagining them to be. Arbitrarily slicing things to match display refreshing rates isn't necessarily viable or efficient from a cpu usage point of view. And if not enough new data is sent and in the end the new drawing has just 1 or 2 milliseconds of new data to display will it be even possible to see the difference in the calculated Fourier transform with the naked eye? I have my doubts.

wwmm commented 3 weeks ago

In a case where pipewire is running at 48 khz and with a quantum of 1024 each buffer would have about 20 milliseconds of data. Maybe it sends several of these buffers between each drawing. Maybe it doesn't. I have no control over this. But depending on how arbitrarily fast someone wants the drawing to go we are talking about slicing buffers that would be on the order of 20 milliseconds.