Double Buffers not well implemented

[manuelbertelli]

Bug Description

Context: https://mixxx.zulipchat.com/#narrow/stream/247620-development-help/topic/vSync/near/423170319

Evidences: Shakking/woobling movement of waveform not synced with graphics cards (currently fixed 60fps with double buffer pattern not well implemented)

Video using Deeree skin at 240fps with less compression achievable (download and watch, best option) https://1drv.ms/v/s!AtB9x7uTAUJlgece5PImCYBq2hhjHw?e=PlaF40

Proposed solution:

Implementing the double buffer pattern in a codebase like Mixxx can help improve synchronization and performance, especially in scenarios involving audio and graphics rendering. While the exact implementation may vary depending on the specific requirements and architecture of the application, here are some general steps to get you started:

Identify Critical Sections: Determine which parts of the codebase are involved in rendering audio and graphics, as well as handling user input and other asynchronous events. These are the critical sections where double buffering can be applied to improve synchronization.

Create Buffer Structures: Define data structures to represent the double buffers for audio and graphics data. For audio rendering, you may have buffers for incoming audio samples, while for graphics rendering, you may have buffers for rendering commands or texture data.

Synchronize Access: Ensure that access to the double buffers is properly synchronized to prevent race conditions and data corruption. Use synchronization primitives such as mutexes or semaphores to coordinate access between producer and consumer threads.

Implement Swap Mechanism: Design a mechanism for swapping buffers between the producer (e.g., audio input, graphics rendering) and consumer (e.g., audio playback, screen rendering) components. This typically involves atomically updating pointers or indices to indicate which buffer is currently being produced or consumed.

Handle Buffer Overflows/Underflows: Implement error handling mechanisms to handle buffer overflows (e.g., when the producer is producing data faster than the consumer can consume) and underflows (e.g., when the consumer is consuming data faster than the producer can produce). This may involve dynamically adjusting buffer sizes or introducing buffering strategies such as buffering and discarding.

Integrate with Existing Components: Integrate the double buffer pattern into existing components of the codebase, such as audio and graphics rendering engines, input handling systems, and event loops. Ensure that the double buffering mechanism works seamlessly with other components and does not introduce performance bottlenecks or synchronization issues.

Test and Debug: Thoroughly test the implementation of the double buffer pattern under various scenarios, including different buffer sizes, production/consumption rates, and system configurations. Use debugging tools and profiling techniques to identify and resolve any performance or synchronization issues.

Given the complexity of the Mixxx codebase and the interactions between audio and graphics rendering, it's important to carefully plan and implement the double buffer pattern to ensure optimal performance and synchronization. Start by identifying the critical sections where double buffering can be applied, and gradually integrate the pattern into the relevant components of the application. If you encounter any specific challenges or need further assistance, feel free to ask!

Pattern design/information/instructions: https://gameprogrammingpatterns.com/double-buffer.html#not-just-for-graphics

Also related: https://gameprogrammingpatterns.com/game-loop.html https://gameprogrammingpatterns.com/sequencing-patterns.html

Version

all

OS

win 11

[m0dB]

We are already using double buffering. I don't have shacky or wobbly movement of the waveforms and neither do others, so this is not a matter of something not being well implemented.

Others have told you before, but you do not seem to understand this, so I tell you again: Your way of communicating is very disrespectful. You do not have the knowledge of the current implementation that others have been investing a lot of time in, you make a lot of assumptions, and yet you come here as if you know it all and better.

If you feel you can make an improvement, do so by creating a pull request.

[manuelbertelli]

https://gameprogrammingpatterns.com/double-buffer.html#not-just-for-graphics

[daschuer]

The issue you have demonstrated in the Zulip thread via screen recording is the bad time reporting of the Windows MME API. It is not recommended to use it with Mixxx. This is well described in the Mixxx manual: https://manual.mixxx.org/2.2/en/chapters/preferences.html#windows If you have interest to fix that anyway you may file a bug about that including some measurements or benchmarks. The related code is documented here: https://github.com/mixxxdj/mixxx/blob/99bc5c200a8672ac99e80588aa7aea6c43bdfde9/src/soundio/sounddeviceportaudio.cpp#L1021

I will close this one now as invalid. And please do not bother use again with not verified assumptions form the gaming domain.

[manuelbertelli]

Thank you, I'll dive further in this pointer you gave me.

[manuelbertelli]

Games handles audio and video and inputs, smoothly. We are trying achieve the same. If it's not smooth, I think there is a path for improvements. I don't think our code is so intense that can't handle a simple problem game development has solved before. So, I do understand your frustrations.