https://bugs.kde.org/show_bug.cgi?id=501716
Emmet O'Neill <emmetoneill....@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REPORTED |CONFIRMED
Ever confirmed|0 |1
--- Comment #10 from Emmet O'Neill <emmetoneill....@gmail.com> ---
@halla I thought that was the case but I'm not too familiar with the different
ways of packaging on Windows.
I was thinking that it might be possible that the packaging for Windows was
somehow messed up, causing the playback engine to automatically fall back from
MLT to Qt (which it'll do if it can't find the proper path for the MLT
resource/profile/preset files). We actually recently had an issue with this on
Linux post qt6 port.
But that *still* can't be it, because we totally removed QtMultimedia form the
basic Qt-based playback engine, so even if MLT failed to load and it had to
fall back, it wouldn't produce any audio at all.
Personally I haven't been able to reproduce this on Linux or Windows with
various mp3 files, so I'm starting to suspect it's a power/performance issue.
Maybe we've set the audio buffer size small by default (this improves latency
and AV sync, but taxes the CPU more). If that's the case then the right
solution might be to make it configurable and start with a slightly more
conservative setting.
If it's not a power issue and Deagan has a relatively powerful PC, then I'm
really not sure and will need to go back to the drawing board and do more
investigation...
--
You are receiving this mail because:
You are watching all bug changes.
