Bug 386932 - Audio playback is different pitch & not smooth.
Summary: Audio playback is different pitch & not smooth.
Status: RESOLVED FIXED
Alias: None
Product: kdenlive
Classification: Applications
Component: User Interface (show other bugs)
Version: 17.08.3
Platform: Appimage Linux
: NOR major
Target Milestone: ---
Assignee: Jean-Baptiste Mardelle
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-15 01:42 UTC by Unknown
Modified: 2017-12-16 05:16 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Unknown 2017-11-15 01:42:01 UTC
Link to audio download audio files for analyses:
https://www.dropbox.com/s/30n02lgpuvcbbst/Benji%20Jackson%20-%20Good%20Time%20Rock%20and%20Roll.ogg?dl=0
https://www.dropbox.com/s/oitdijpozgwk6c8/Benji%20Jackson%20-%20Good%20Time%20Rock%20and%20Roll.wav?dl=0

BEHAVIOR
I'd imported an audio file in both .wav and .ogg file formats to use as background music. Playback in Clip Monitor does not play back clip in real time and the pitch of the audio clip is higher than if you would play it via a media player outside of Kdenlive. Also seems like the clip is playing back a little faster than normal speed, on both files. This is also reflected when clips are added to Timeline.

EXPECTED BEHAVIOR
That the audio file would play smoothly, in real-time playback and with correct pitch & speed, both in Clip Monitor/Project Monitor playback, as well as rendering and final rendered media.

BUG DISCOVERED WHILE USING
Kdenlive 17.08.3 (Appimage)
Linux Mint 18.2 x64 (Ubuntu-base)
Cinnamon 3.4.6
Nvidia GTX 980ti Graphics
Nvidia 384.98 proprietary graphics driver
Comment 1 Unknown 2017-11-15 01:45:18 UTC
UPDATE #1: Just tested playback of the same files in Kdenlive 17.04.3 (the last stable release on Mint 18.2 via ppa), and there was no pitch issue -- it played as expected, though still a little choppy (which is surprising considering the processing power in my editing bay PC's).
Comment 2 Unknown 2017-11-16 00:39:42 UTC
UPDATE #2: Opened the same project in a non-Appimage of Kdenlive 17.08.2, and the audio plays fine. No pitch variation in the Clip Monitor or the final render.

(Tested on Kdenlive 17.08.2 on Ubuntu 17.10 64-bit, GNOME 3.26 desktop)
Comment 3 Jean-Baptiste Mardelle 2017-11-16 12:48:46 UTC
Thanks Jesse for the investigation.
That seems to indicate a regression in MLT.
I will test your audio files tomorrow
Comment 4 Unknown 2017-11-16 19:23:36 UTC
Thanks JB. No rush. If Appimages can be solid enough as native installs, this can be a huge leap for Kdenlive.
Comment 5 Jean-Baptiste Mardelle 2017-11-19 18:45:57 UTC
Ok so that one seems unrelated to Kdenlive. I easily reproduced the bug as you described with the latest git, while it played correctly with the 17.08.2 AppImage. After testing against several MLT verions I could not find the problem. However after many tests it seems like this is related to KDE's audio mixer. It now allows to control the sound level by application and mine for Kdenlive was set to 139% which caused clipping & pitch issue. Setting it back to 100% gave me a correct playback. Can you check if you have such an option in your sound settings ? Still, not sure why the level had been raised like this.
Comment 6 Unknown 2017-11-19 20:53:07 UTC
Thanks for looking into this. On Mint 18.2 (Cinnamon 3.4.6 desktop), there is an option in Sound Settings for application-specific volume control. Kdenlive (specifically titled "ALSA plugin [kdenlive]") was set at 100%, but there's no option to increase volume beyond 100%. Changing the volume in that setting, however, doesn't change the improper pitch or speed of playback in Kdenlive 17.08.3 appimage. 

Just tested the .ogg file with 17.04.3 (non-Appimage) on Mint 18.2 & 18.03.70 git master (non-Appimage) on Ubuntu 17.10 x64. The result is no pitch variation, no speed difference from original file. Everything works fine on these builds.

So is it Appimage-specific, then? If not Kdenlive, is it a problem with the Appimage file format itself? I'm only saying because editors who use the Appimage (esp. if it's being advertised as stable) will fundamentally be expecting proper playback of supported media files. Issues like this will be a major red flag against the program. (Thankfully the non-Appimages work alright.)
Comment 7 Unknown 2017-11-30 20:37:32 UTC
UPDATE #2: I tested the 17.08.3 Appimage on Ubuntu 17.10 and opened an older edit project I did from back in July. different mp3 audio files; but same result. The audio is higher in pitch and is faster than it should be.

Opening on Ubuntu 17.10 with the non-Appimage of the git master does not produce this bug; plays fine.
Comment 8 Jean-Baptiste Mardelle 2017-12-01 14:29:26 UTC
I still don't understand where the problem comes from. But if you go to Kdenlive Settings > Playback and play with the SDL Audio Driver (Setting it to Alsa, OSS, Default, Alsa, and back to Default) and playing the clip between switching to a different mode, at some point the bug seems to disappear. Not a very professional fix but can you try ?
Comment 9 Unknown 2017-12-01 18:22:58 UTC
I got it to work one time, but the solution provided intermittent results. Sometimes it worked. Sometimes no change. Tried with .ogg files, .wave files, and .mp3 files, playing back in both Clip & Project Monitors.

Do the guys who develop the .Appimage containers have any support at all? Could they offer a lead?
Comment 10 Unknown 2017-12-08 19:38:09 UTC
UPDATE #4: Testing the upcoming 17.12 Appimage (via https://files.kde.org/kdenlive/release/kdenlive-17.12.0-x86_64.AppImage.mirrorlist). Upon opening the program, importing the audio file in the original post, and played back in Clip Monitor. Same issue. I switched the Audio driver from "Automatic" to "OSS", and tried playing the audio file again. The issue was resolved.

So, there is still an issue where the expected behavior isn't working out-of-the-box on 17.12 and Ubuntu 17.10 (gnome desktop). I don't think it's advisable to expect the user to change the audio device setting after opening Kdenlive every time, yeah?
Comment 11 Unknown 2017-12-08 19:46:00 UTC
UPDATE #5: Closing Kdenlive, re-opening, and re-importing the audio file ends up producing the same playback issue (even after Audio drive was changed from automatic to OSS).
Comment 12 Jean-Baptiste Mardelle 2017-12-14 00:16:58 UTC
Ok, finally after spending many hours checking for regressions in the toolchain I think I understood what happened. Recently, FFmpeg and thus MLT dropped the avresample filter.

Before that change, MLT could use either libavresampleSo when an audio file needs to be libsamplerate of FFmpeg's avresample filter. The AppImage only relied on FFmpeg's avresample, so when it was dropped, we were left without resampling, leading to the distortion reported.

I have now updated the AppImage to include libsamplerate which can now be used be MLT for resampling tasks.

An updated AppImage is currently uploading at: 
https://files.kde.org/kdenlive/release/kdenlive-17.12-x86_64.AppImage.mirrorlist

(File should be about 170Mb and should be ready in 45 minutes)
Please test whenever you can
Comment 13 farid 2017-12-14 01:54:16 UTC
Wow JB very important fix. Thanks for your effort. I have requested the user who experienced the same problem to test it. Cheers :D
Comment 14 farid 2017-12-14 03:39:17 UTC
This seems to be fixed! Is there still time to commit it?
Comment 15 Jean-Baptiste Mardelle 2017-12-14 07:02:12 UTC
Fortunately this is a packaging issue. No change is required on Kdenlive's code. It simply means that packagers should be aware that libsamplerate is now a mandatory dependency. Waiting for Jesse's confirmation so we can close this one!
Comment 16 Unknown 2017-12-14 07:57:02 UTC
Just tested with the latest Appimage build JB provided. I can confirm: no more pitch issue using .ogg or .wav audio files (even with audio driver set to "Auto" in Kdenlive). Really nice work sir. :) Your time and efforts really paid off on this one.
Comment 17 Unknown 2017-12-16 05:16:56 UTC
Re-tested with 17.12 stable release. Confirmed fix. Brilliant. :)

Marking as resolved/fixed.