Remove the FIFO thread

[sakertooth]

Removes the FIFO thread, which was a thread used in the audio engine that wrote chunks of rendered audio buffers to a circular buffer, while the audio callback thread would read from that. Instead, the audio callback is the one rendering the buffers directly and doing any chunking as necessary.

The functionality this thread brought allowed for buffers to be "written ahead" of the audio callback, meaning that the FIFO thread would be rendering buffers as fast it can, stopping when it can't write any more buffers, while the audio callback would be reading them at a fixed interval. However:

1. Since the priority of this thread was the same as every other thread running on the system (i.e., not high priority), while the audio callback is commonly thought to run on high priority, it is more likely that the FIFO thread wouldn't have gotten much time to do its task of rendering (i.e., a high priority task). Moving that work into the audio callback is better in this case.
2. Even if the FIFO thread had high priority, it would have to compete with the audio callback's high priority as well. If we assume that the FIFO thread had high priority, but just a little bit less than the audio callback, then for buffers like 64, 32, etc, the audio callback thread will be running so frequently that we run the risk of not being able to render any buffers at all since the FIFO thread may not have a large enough time slice.
3. The latency wasn't completely determined by the buffer size, but also by how long it took to get this thread running since it was the one rendering the buffers.
4. Very strange deadlocks happened because of this thread. For example, simplifying the thread communication in this case fixes Constant freezing at 0% during export #7320.

This PR also greatly simplifies the transmission of buffers between the engine and the audio device. AudioDevice::nextBuffer is a new function that handles and correctly processes the chunks of audio returned by the audio engine, and also manages both interleaved and non-interleaved outputs. This removes a lot of repetitive code in each audio device that originally was handling their configuration on their own.

This PR also makes ALSA use floating-point audio instead of int16.

[sakertooth]

Changed the PR to still remove the FIFO thread but keep the chunking of the buffer size (to avoid problems with non sample accurate automation but to also fix the problems this thread has caused).

[Rossmaxx]

This shoulda had higher priority. @LMMS/testers

[Rossmaxx]

Wait the tester role is only for peki?

[Rossmaxx]

The fatloss on this is insane. I am not approving for now because I am doubtful if something might have gotten lost somewhere. I will approve after i get around to testing.

Also, don't understand what is now happening with the chunking mechanism. Is the audio thread processing in chunks of 256 and then outputting to the playback/export at the user defined buffer size? Or is there something I missed.

[bratpeki]

@LMMS/testers

Reporting!

I'm busy with managing #7477, #7444 and #7366.

Is this making the code more readable without reducing performance? Or is it a performance boosting PR? In any case, great stuff, I'll look at it when I'm done with these three PRs!

[Rossmaxx]

This is supposed to solve the performance degradation on master compared to 1.2 and the rare case with deadlocks making a mess, along with the buffer size and automation performance, among other stuff. @sakertooth correct me if I'm wrong. If what i guess is right, this PR has the potential to straighten up a lot of the performance bugs.

[bratpeki]

Wait the tester role is only for peki?

For the time being, yeah. I think I get rights to review PRs and whatnot, so it's probably not wise to give it away to anyone wanting to test, but I'm not entirely sure about if that's how it behaves, just speculation.

[sakertooth]

This is supposed to solve the performance degradation on master compared to 1.2 and the rare case with deadlocks making a mess, along with the buffer size and automation performance, among other stuff. @sakertooth correct me if I'm wrong. If what i guess is right, this PR has the potential to straighten up a lot of the performance bugs.

It's mostly to fix deadlock bugs involving this thread waiting forever to close. It's less of a performance benefit (though that could be possible) but more so to simplify the thread communication within the audio pipeline.

[CorruptVoidSoul]

So I tested this PR.
Exporting works fine, no hearable differences.
Playback is still pretty much the same as on master, I made it play the performance intensive part of a song, my phone is still in pain, no noticeable gain or loss there.
I had two random crashes but I expect this to be a me problem because well, it's a phone and this mmpz is uhh... a bit tough sometimes.
Still on the "me problem" side, usually Equalizer takes a minute to load for the first time, in this PR it takes 30 seconds so it's better, not gonna complain.
Now back on playback, the playhead will desync itself from the actual sound after a huge lag spike, but that's a general performance problem, it doesn't have much to do with this PR I think.

Final feedback is this seems good, did Peki test that too ? There could be differences with a computer that can handle heavy workload.

[sakertooth]

Final feedback is this seems good, did Peki test that too ? There could be differences with a computer that can handle heavy workload.

I don't think Peki has tested this yet, but they're probably busy with other PRs so it's fine. Thank you for testing this for me 👍

[sakertooth]

Also, don't understand what is now happening with the chunking mechanism. Is the audio thread processing in chunks of 256 and then outputting to the playback/export at the user defined buffer size? Or is there something I missed.

Sorry, just realized that I didn't answer this question @Rossmaxx. What happens is that the user selects their desired buffer size and audio device to use, and then when LMMS starts, the audio device thread starts, which periodically calls renderNextBuffer, which either returns the latest rendered chunk (256 sample frames per chunk), or calls the overloaded variant for renderNextBuffer to render any buffer size wanted (e.g. 1024 frames). All of the audio devices call the overloaded variant for renderNextBuffer to be able to render any desired buffer size for real-time playback.

There is one thread requesting data periodically. That's it. There are other worker threads that do the actual processing, but this is the only thread requesting data (if not that thread then the export thread). To compare this to before, there was an additional thread, but this was removed, as it was mostly unnecessary and causing issues.

[bratpeki]

I could test this, if it's ready to be tested, or needs WIP testing. @sakertooth ?

[sakertooth]

I could test this, if it's ready to be tested, or needs WIP testing. @sakertooth ?

There were merge conflicts, so I'm still working on this. I'll let you know if its ready 👍

[sakertooth]

Should be ready @bratpeki.

[bratpeki]

Please request a review so I see it on the GitHub UI :)

[bratpeki]

Okay, so, how do I test this?

[sakertooth]

Okay, so, how do I test this?

See if there's any funny business going on when playing demos/exporting on various audio devices. There shouldn't be any audio glitches, crashes, deadlocks, things of that nature (except for soundio which I believe was already broken in master).

[bratpeki]

Tested again, @rdrpenguin04. Everything works well!