search

hydrogen-music / hydrogen

The advanced drum machine for Linux, macOS, and Windows
http://www.hydrogen-music.org
GNU General Public License v2.0
1.03k stars 172 forks source link

LADSPA processing time while idle #1382

Open theGreatWhiteShark opened 2 years ago

theGreatWhiteShark commented 2 years ago

Hydrogen version * : Operating system + version : Linux Audio driver + version :

For some reason the time to process the LADSPA effects in Hydrogen is about 2-3 times higher if Hydrogen is either idle or a part of a song is reached without any notes or patterns. Once there is work to do the total processing time rises and the LADSPA one shrinks. There is probably something we can do about this.

cme commented 2 years ago

I must admit this one seems very strange and i can't seu any muchanism by which i could be happening. Have you got anywhere with it? The symptom geels like a reporting issue; we should expect that the ladspa time is constant, and when there's no notes to render, that constant is a larger proportion of the overall audio processing time, but not any larger than usual, so it feels like it's easy to misreport?

theGreatWhiteShark commented 2 years ago

I haven't looked into it yet. But it definitely rings a bell. Somewhere I did read about this behavior in the past. AFAIR the argument goes like this: if there is no highly correlated signal but only an uncorrelated noise floor processing is more expensive. But I don't recall where I read about this. Maybe linear filter theory, maybe a manual or other DSP/electronic literature or even time series analysis stuff during PhD. In any case, it's too far away to just point the finger at it :) Nevertheless, it feels somewhat expected. But for performance reasons we should deal with it.

My idea to fix this to integrate a noise gate in the processing line. We could either set an arbitrary threshold or add a flag using which the samplers tells whether it added any content. Below threshold or with no more samples added we just bypass the LADSPA processing.

cme commented 2 years ago

I finally found the time and brain space to think about this a bit more and work out why it wasn't sitting well with me.

Firstly, this feels like it's a bug, or at least undesirable behaviour, on the part of some particular plugin. It's not true for all plugins, and it's not true for FFT, but I think it can be true for a general iterative Fourier transform. If a plugin is doing something like that, it should probably implement a simple zero-detect on its own. If you can isolate which plugins you use that are doing this, we can probably fix them ;)

The other issue is that it's not the right thing, functionally speaking, for all effects. Something implementing a long delay line or reverb would be expected to produce output for some time after any input, based on its internal state.

If someone wants to use plugins from each of these categories in the same song, I guess it would have to be individually controllable per each plugin? And maybe with a controllable 'timeout' parameter?

cme commented 2 years ago

Oh, I should say also, these are reasons I felt uneasy about it, and are not sufficient reasons to not do it! :)

theGreatWhiteShark commented 2 years ago

Firstly, this feels like it's a bug, or at least undesirable behaviour, on the part of some particular plugin. It's not true for all plugins, and it's not true for FFT, but I think it can be true for a general iterative Fourier transform. If a plugin is doing something like that, it should probably implement a simple zero-detect on its own. If you can isolate which plugins you use that are doing this, we can probably fix them ;)

Yes. When rethinking it, it still rings a bell that processing noise is more expensive but

  1. This will apply for (if any) a fraction of all plugins
  2. and it won't apply at all since Hydrogen is supposed to hand over arrays filled with plain zeros instead of a noise floor whenever there is nothing to play back

I stumbled across this one when asking myself whether buffer size set in the Preferences must be some power of two. But it turned out this is not the case at all for a wide range of plugins I tested. (I also searched through the source code of a couple of LADSPA libraries and couldn't find a single one using FFT. I'm not that much into DSP, so, I was quite surprised.) The way I tested the performance of the plugins was to simply print the average ladspaTime_end - ladspaTime_start together with the average overall processing time. I did so for at least four different plugins (amp_mono from the CMT, satanMaximiser from SWH, fmOsc from SWH, and PhaserII from CAPS). AFAIR LADSPA time went up for all of them. But it's possible I messed something up.

The other issue is that it's not the right thing, functionally speaking, for all effects. Something implementing a long delay line or reverb would be expected to produce output for some time after any input, based on its internal state.

If someone wants to use plugins from each of these categories in the same song, I guess it would have to be individually controllable per each plugin? And maybe with a controllable 'timeout' parameter?

I'll try to verify this issue soon (after tweaking/merging the GUI update) and check whether this is present/fixed in other LADSPA hosts. You are right, it feels wrong.