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
