GNOME Bugzilla – Bug 763870
concat, cdparanoiasrc: silence gap 500ms between two tracks
Last modified: 2018-05-06 12:21:16 UTC
Created attachment 324259 [details] audacity screenshot of gap When playing gaplessly two tracks with concat element there is 500ms gap between tracks. The original tracks do not have gaps at the ends(verified by audacity). The problem happens with pipe: gst-launch-1.0 concat name=c cdparanoiasrc read-speed=2 paranoia-mode=0 track=1 device=/dev/sr1 ! queue ! c. cdparanoiasrc track=2 read-speed=2 paranoia-mode=0 device=/dev/sr1 ! queue ! c. c. ! audioconvert dithering=0 ! audioresample quality=0 ! alsasink sync=false By putting queue before alsasink does not solve the problem: gst-launch-1.0 concat name=c cdparanoiasrc read-speed=2 paranoia-mode=0 track=1 device=/dev/sr1 ! queue ! c. cdparanoiasrc track=2 read-speed=2 paranoia-mode=0 device=/dev/sr1 ! queue ! c. c. ! audioconvert dithering=0 ! audioresample quality=0 ! queue max-size-time=1000000000 max-size-bytes=0 max-size-buffers=0 ! alsasink sync=false Known ugly workaround(cuts of the last part of second track, but the switch is really gapless): When I add bigger buffer at alsasink the gap is not there: gst-launch-1.0 concat name=c cdparanoiasrc read-speed=2 paranoia-mode=0 track=1 device=/dev/sr1 ! queue ! c. cdparanoiasrc track=2 read-speed=2 paranoia-mode=0 device=/dev/sr1 ! queue ! c. c. ! audioconvert dithering=0 ! audioresample quality=0 ! queue max-size-time=1000000000 max-size-bytes=0 max-size-buffers=0 ! alsasink sync=false
The workaround solution with using bigger buffer at sink do cut off the last part of second track. I tested with file with marks at the beginning and at the end of file. First track is 5 seconds second is 6 seconds. Output has 9 seconds as shown on attached picture from audacity.
Created attachment 324270 [details] cutoff last 2 seconds when using workaround The mentioned cutoff when using workaround solution. track1 5secs - with marks at both ends track2 6secs - with marks at both ends output 9secs
Created attachment 324279 [details] filesink no cutoff When putting output into filesink the output is not cutoff.. so this indicates problem in alsasink or ringbuffer. This is the pipeline with exactly the same CD as in previous message: gst-launch-1.0 concat name=c cdparanoiasrc read-speed=2 paranoia-mode=0 track=1 device=/dev/sr1 ! queue ! c. cdparanoiasrc track=2 read-speed=2 paranoia-mode=0 device=/dev/sr1 ! queue ! c. c. ! audioconvert dithering=0 ! audioresample quality=0 ! queue max-size-time=1000000000 max-size-bytes=0 max-size-buffers=0 ! wavenc ! filesink location=output.wav
Created attachment 324426 [details] analysing the samples before ringbuffer and before alsa Another test on workaround solution (why it cuts off the end of track 2) Record audio output with audacity and at the same time fwrite before ringbuffer and before writing to alsa. We see that before ringbuffer the data are there but when read from ringbuffer before writing to alsa they are missing. It seems there is some bug or something in ringbuffer. Attached screenshots and altered gstreamer code. This is the pipeline: gst-launch-1.0 concat name=c cdparanoiasrc read-speed=2 paranoia-mode=0 track=1 device=/dev/sr1 ! identity name=cd1 silent=false ! queue max-size-time=120000000000 ! c. cdparanoiasrc device=/dev/sr1 track=2 read-speed=2 paranoia-mode=0 ! identity name=cd2 silent=false ! queue max-size-time=120000000000 ! c. c. ! audioconvert dithering=0 ! audioresample quality=0 ! identity name=sinkin silent=false ! alsasink buffer-time=1000000 sync=false
Created attachment 324427 [details] [review] code for fwrite test diff for analysis of samples between ringbuffer commit and before alsa write from previous message.
Created attachment 324437 [details] testing track with marked beginning/end The workaround cutoff issue can be triggered even without cd mechanic: gst-launch-1.0 concat name=c filesrc location=/tmp/track_2side.wav ! wavparse ! queue ! c. filesrc location=/tmp/track_2side.wav ! wavparse ! queue ! c. c. ! audioconvert dithering=0 ! audioresample quality=0 ! alsasink buffer-time=1000000 sync=false When used the patch for writing into file before/after ringbuffer you will see the difference (before ringbuffer the samples are there, after ringbuffer they are missing)
Using few days old 1.6 branch code of gstreamer. I already have commit: commit c5ad081b92ad2008f35f666734084d4639ba5aaa Author: Sebastian Dröge <sebastian@centricular.com> Date: Sun Mar 13 10:33:53 2016 +0200 baseparse: Recheck after pre_push_frame() if there are tags pending
Found out that when using audiomixer after concat (before alsasink) with combination of using queue before audiomixer the gap is not there. I suspect that after switching to second track the timestamp of buffers(or maybe its caused by segment event new time segment) is changed to 0:00 which maybe triggers some bug/logic in ringbuffer. I also had to shorten the ringbuffer (buffer-time of alsasink) in order to not cut-off the end of track2. This is the working pipeline: gst-launch-1.0 concat name=c cdparanoiasrc read-speed=2 paranoia-mode=0 track=1 ! queue name=cd1 max-size-time=120000000000 ! c. cdparanoiasrc track=2 read-speed=2 paranoia-mode=0 ! queue name=cd2 max-size-time=120000000000 ! c. c. ! audiomixer ! audioconvert dithering=0 ! audioresample quality=0 ! queue max-size-time=120000000000 ! alsasink buffer-time=20000 sync=false
Does the patch from https://bugzilla.gnome.org/show_bug.cgi?id=764120 help ?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!