By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 3155 - Playback speed too fast when starting/resuming play
Summary: Playback speed too fast when starting/resuming play
Status: RESOLVED NOTOURPROBLEM
Alias: None
Product: TDE
Classification: Unclassified
Component: non-core programs (show other bugs)
Version: R14.0.x [Trinity]
Hardware: Other Linux
: P5 normal
Assignee: Timothy Pearson
URL:
Depends on:
Blocks:
 
Reported: 2020-08-05 13:52 CDT by Jan Stolarek
Modified: 2020-08-14 06:49 CDT (History)
3 users (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name:


Attachments
Incorrect beginning of a song (98.13 KB, audio/mpeg)
2020-08-05 13:52 CDT, Jan Stolarek
Details
Correct beginning of a song (107.36 KB, audio/mpeg)
2020-08-05 13:53 CDT, Jan Stolarek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Stolarek 2020-08-05 13:52:12 CDT
When I start playback in Amarok by:

  - playing a new song when no song was playing before
  - manually switching to a new song when a song is already playing
  - unpausing a paused song

for a split second the playback speed is uneven, i.e. it gets a noticeably too fast.  In the case (3) above if the pause was long there's often an additional audible crack (as if an mp3 was ripped from a scratched CD) several seconds after unpausing. This happens only with PulseAudio output plugin. I was unable to reproduce the bug with any other application using PulseAudio as a backend (Firefox, Chrome, VLC). I was also unable to reproduce the bug on another machine that theoretically has the same software configuration (Debian Buster + TDE 14.0.9). Finally, the bug does not happen when a song ends and Amarok moves to the next song on a playlist.

I will attaching two recordings: one where a song plays correctly (created using ALSA output plugin) and the second one where the incorrect song tempo can be heard. Both recordings have 2 seconds of leading silence (to avoid audio distortion described in this bug report) and two trailing seconds (to avoid bug 3088).
Comment 1 Jan Stolarek 2020-08-05 13:52:46 CDT
Created attachment 2985 [details]
Incorrect beginning of a song
Comment 2 Jan Stolarek 2020-08-05 13:53:03 CDT
Created attachment 2986 [details]
Correct beginning of a song
Comment 3 Michele Calgaro 2020-08-06 04:17:32 CDT
Hi Janek,
does this happen with the xine engine or akode engine? If it happens with the xine engine, would you be able to check if xine itself (as application) gives the same problem?
Comment 4 Jan Stolarek 2020-08-06 05:13:22 CDT
The bug also happens for standalone xine, but only at the start of playback and *not* after unpausing.

Can I use akode engine without arts?
Comment 5 Jan Stolarek 2020-08-06 06:49:50 CDT
Just tested and the problem does not happen with akode. (Aside: akode is unusable because of ~5 second lag, which I will report as a separate bug.)
Comment 6 Jan Stolarek 2020-08-12 10:30:31 CDT
After some more debugging I realized that was not a problem with Amarok or xine but with PulseAudio module-combine-sink module, which I'm using to work around current limitations of KMix. Long story short: upgrading PulseAudio from version 12.2 (default shipped with Debian 10) to 13.0 (provided by Backports) solved this and several other sound problems I was experiencing.
Comment 7 Michele Calgaro 2020-08-12 23:06:29 CDT
Ok, good to know Janek :-)
Comment 8 Jan Stolarek 2020-08-14 06:49:30 CDT
Unfortunately, I was too optimistic about upgrade to newer PulseAduio being helpful - looks like I just go lucky. But anyway, this isn't Trinity problem. I reported the bug upstream:

https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/965