https://bugs.kde.org/show_bug.cgi?id=439537

            Bug ID: 439537
           Summary: Kwave audio stutters when loading files or redrawing
                    UI
           Product: kwave
           Version: 21.04.2
          Platform: Other
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: general
          Assignee: thomas.eschenbac...@gmx.de
          Reporter: nyanpas...@tuta.io
  Target Milestone: ---

SUMMARY
If I begin Kwave audio playback, and load new files or perform UI operations,
the audio stutters.

STEPS TO REPRODUCE
1. Open Kwave and open an audio file.
2. Begin playback.
3. Change the zoom level, or load a new audio file.

OBSERVED RESULT
Playback stutters while Kwave is working.

EXPECTED RESULT
Playback does not stutter.

SOFTWARE/OS VERSIONS
Operating System: Arch Linux
KDE Plasma Version: 5.22.2
KDE Frameworks Version: 5.83.0
Qt Version: 5.15.2
Kernel Version: 5.12.14-zen1-1-zen (64-bit)
Graphics Platform: X11
Processors: 12 × AMD Ryzen 5 5600X 6-Core Processor
Memory: 15.6 GiB of RAM
Graphics Processor: NVIDIA GeForce GT 730/PCIe/SSE2

ADDITIONAL INFORMATION
I'm looking into Kwave as an alternative to Audacity, given the recent Muse
takeover and controversies, as well as reports of poor code quality. Is this
stuttering due to Kwave's legacy code design, or due to maintainers who aren't
experienced in wait-free audio? Looking at
https://invent.kde.org/multimedia/kwave/-/commits/master/, it's been literally
6 months since Kwave's most recent non-metadata commit.

I'm open to contributing or maintaining Kwave, if it's possible to fix or work
around whatever degree of technical debt is present, and if existing
maintainers want more improvements.

I have some experience in developing audio apps. In order to play audio without
stuttering, the general technique is to isolate audio playback on its own
thread which progresses without the possibility of blocking on the UI, and
communicate between the threads using wait-free constructs (which often require
tailoring to a particular application or even restructuring an app around
minimizing shared state), mutexes held for as short of a period as possible
(easier to retrofit into a program, but less reliable at eliminating stuttering
altogether), or performing data races and praying nothing bad happens (OpenMPT
does that in some cases and it seems to work).

For background, see
http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing.
For a real-world example of how Firefox handles wait-free audio, see
https://news.ycombinator.com/item?id=27128087.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to