reduce sample buffer memory usage

[abique]

This set of changes reduce the amount of memory used by the application for storing audio samples.

Here two memory dump (SVG), before and after so you can compare.
pprof-after
pprof-before

I had a look over BalanceGroupState, and this one is safe to shrink.

[abique]

I'll take a look at the compiler errors later today, this is strange my build didn't pick it up.

[abique]

I've run the tests and some failed:

[  FAILED  ] 7 tests, listed below:
[  FAILED  ] AnalyzerWaveformTest.canary
[  FAILED  ] EngineMixerTest.SingleChannelOutputWorks
[  FAILED  ] EngineMixerTest.SingleChannelPFLOutputWorks
[  FAILED  ] EngineMixerTest.TwoChannelOutputWorks
[  FAILED  ] EngineMixerTest.TwoChannelPFLOutputWorks
[  FAILED  ] EngineMixerTest.ThreeChannelOutputWorks
[  FAILED  ] EngineMixerTest.ThreeChannelPFLOutputWorks

Let's see if it is a regression.

[abique]

The regression is caused by: constexpr unsigned int MAX_BUFFER_LEN = 32 * 1024;.
Maybe there is a problem within the test itself.

[abique]

Actually the problem found by the test suite is in the test itself.
It doesn't correctly compare the output and the reference:

The test will perform a for loop to consume all the input and only the latest block will remain in memory, while it will then compare it to the full length buffer.

[Swiftb0y]

sorry for the pedantic comments in regards to our codestyle, but we really want to maintain some consistency here. If there are good reasons to change something we'd love to discuss possible improvements.

[abique]

sorry for the pedantic comments in regards to our codestyle, but we really want to maintain some consistency here. If there are good reasons to change something we'd love to discuss possible improvements.

It is your house, keep it clean. 👍

[abique]

Regarding the max buffer size, a few thing.

1. it can't be too big, otherwise the GUI will feel bad (vu meters don't refresh often for example)
2. latency is bad, especially for live performances; I personally think that 256@44.1 is a safe default, 1024@44.1 already feels like shit.
3. I don't know how often you get the MIDI info, and if you run them ASAP or if you shift them within the block to avoid jitters, but anyway, at large blocks you'll probably feel more "jittery"

I don't think there is a point in working in higher sample rate than 48K except if your HW can't do it.

Then in soundmanagerconfig.h:

    // Size1xms presents the first buffer size of 2^X
    // that results in a buffer time above 1 ms
    // It is 1.45 ms @ 44.1 kHz
    // The other values are representing the following 2^X sizes.
    enum class AudioBufferSizeIndex {
        Size1xms = 1,
        Size2xms = 2,
        Size5xms = 3,
        Size10xms = 4,
        Size20xms = 5,
        Size40xms = 6,
        Size80xms = 7,
    };

    // Represents the sample rate independent frame/period
    // index values in case of Jack
    enum class JackAudioBufferSizeIndex {
        SizeAuto = 5,
        Size2048fpp = 6,
        Size4096fpp = 7,
    };

static constexpr auto kMaxAudioBufferSizeIndex =
            static_cast<unsigned int>(AudioBufferSizeIndex::Size80xms);
static constexpr auto kDefaultAudioBufferSizeIndex =
            static_cast<unsigned int>(AudioBufferSizeIndex::Size20xms);

So at 44.1, min is 64 samples, max 4096.

Now the sample rate:

    static constexpr value_t kValueMin = 8000;   // lower bound (inclusive, = minimum MP3 sample rate)
    static constexpr value_t kValueMax = 192000; // upper bound (inclusive)

You've decided to support up to 192kHz.
According to dlgprefsound.cpp, then you'll let the user choose up to 16384.

Here I suggest three things:

1. Make the max buffer size at 44.1kHz to 1024 frames or at most 2048. Really 1024 already feels like shit, so I don't think that there's anything good in letting the user put himself in a bad experience. I think pipewire's default is 512 at 44.1?
2. Limit the max buffer size to 4K, even if the user is at 192kHz. If you want to run at 192kHz, then you probably can afford a low latency (or just use a lower sampling rate...).
3. Limit the samplerate to 96kHz

I really think that offering 2K at 44.1kHz is not a service to the user.

Let me know in which direction we're going and I'll adjust the settings dialog and clamp it well.

[Swiftb0y]

I'm not familiar with many parts of the audio engine, but I think we already do support low latency's via low periods, the thing is just that sometimes we just allocate MAX_BUFFER_SIZE upfront but only use the fraction defined by the user. Thats why there is high memory size, but still reasonable latency.

I don't think there is a point in working in higher sample rate than 48K except if your HW can't do it.

That might be true for the majority of users, but some users still want that higher samplerate. Same applies for latency (better to have high latency and no underruns instead of constant underruns). Unless this forces us to make tradeoffs that worsens the experience for the majority, I don't see why we shouldn't support those buffer sizes & samplerates.

I really think that offering 2K at 44.1kHz is not a service to the user.

I think its reasonable to expect users to know what settings they're choosing. If people want to use those settings because they might be forced to its better to let them instead of patronizing them in that regard.

[abique]

I think its reasonable to expect users to know what settings they're choosing. If people want to use those settings because they might be forced to its better to let them instead of patronizing them in that regard.

Not necessarily, it could be that someone just wants to try mixing, doesn't know about buffer size and its implications and ends up with a setting leading to a bad user experience.

Having more options doesn't means a better beginner experience.

Let's keep the current settings then, but maybe consider advertising 256@44.1kHz as a good default (or even 128). Currently the drop down menu doesn't give any hint, maybe add an auto entry which will pick a good default?

[Swiftb0y]

Yes, we should definitely try to choose a good default, but we shouldn't take options away from power users or people that know what they're doing just so beginners don't accidentally choose the wrong setting.

[abique]

Something you could consider, is to always run the engine at 44.1kHz or 48kHz, and then down/up sample before reading/writing to the audio interface.

[abique]

I've made MAX_BUFFER_LEN back to were it initially was and tried to use kMaxEngineSamples or kMaxEngineFrames when applicable.

[abique]

BTW, I've run the tests with ASAN.
I've also run the application with ASAN, played a few tracks, used some effects, pitch up/down, stretch... I didn't test everything but I've done basic testing and it was working.

[abique]

Hi,
Did anyone had a chance to review the changes?
Are you happy now?

[daschuer]

Yes, I had a brief review and it looks good now. I just want to do some test. Hope I find time soon.

[daschuer]

All is working good. Thank you very much.