rjvbb added a comment.
That's a nicety, not necessarily a requirement, at least not for playing notification sounds. Just how often do you get sound alerts at such high rates that caching becomes unavoidable, before you get mad and resolve the issue or yank the plug? I think that proper cross-platform support without requiring multiple 3rd-party libraries is more important than being able to leverage PA caching directly. With QMM, playing audio can be as simple as player = new QMediaPlayer; player->setMedia(QUrl::fromLocalFile("/path/to/audio.whatever")); player->play(); That doesn't look like "sound middleware madness" to me, is probably much easier than leveraging "sound lowerware" directly and the documentation suggests this class has buffering support. The lower-level and audio-only QAudioOutput requires a bit more coding but I'd say it's still preferrable over introducing new external dependencies. If not already the case, PA caching can probably be leveraged from QMediaPlayer, and if that's justifiable it shouldn't be hard to upstream such a modification. > GStreamer works on all major operating systems such as Linux, Android, Windows, Max OS X I know it works on Mac (and MSWin) but that doesn't make it "native". I also know what it depends on (the basic MacPorts port:gstreamer1 will pull in GTk3). I'd say that's not even acceptable for a KDE requirement on any Unix variant; introducing such a dependency on Mac (or MSWin) is going against the current flow of making KDE a proper and as-native-as-possible citizen on those platforms. REPOSITORY R289 KNotifications REVISION DETAIL https://phabricator.kde.org/D14397 To: broulik, #frameworks, dfaure, davidedmundson, sitter, drosca, kfunk, rjvbb Cc: nicolasfella, kde-frameworks-devel, michaelh, ngraham, bruns