alsasink/audiobasesink: Always drops very first sample
When playing a 44.1 kHz MP3 file using pipeline:
gst-launch-1.0 filesrc location="audio.mp3" ! mpegaudioparse ! mpg123audiodec ! audioconvert ! alsasink
I noticed that it always drops the first sample:
0:00:00.069389500 6832 0xaaaacdc460a0 DEBUG audiobasesink gstaudiobasesink.c:1934:gst_audio_base_sink_render:<alsasink0> sync-offset +0:00:00.000000000, render-delay 0:00:00.000000000, ts-offset +0:00:00.000000000
0:00:00.069426250 6832 0xaaaacdc460a0 DEBUG audiobasesink gstaudiobasesink.c:1997:gst_audio_base_sink_render:<alsasink0> running: start 0:00:00.000000000 - stop 0:00:00.026122448
0:00:00.069461125 6832 0xaaaacdc460a0 DEBUG audiobasesink gstaudiobasesink.c:2039:gst_audio_base_sink_render:<alsasink0> final timestamps: start 0:00:00.000000000 - stop 0:00:00.026122448
0:00:00.069487000 6832 0xaaaacdc460a0 DEBUG audiobasesink gstaudiobasesink.c:2080:gst_audio_base_sink_render:<alsasink0> Clipped start: 1151/1152 samples
0:00:00.069506125 6832 0xaaaacdc460a0 DEBUG audiobasesink gstaudiobasesink.c:2103:gst_audio_base_sink_render:<alsasink0> resync after discont/resync
New clock: GstAudioSinkClock
0:00:00.069530375 6832 0xaaaacdc460a0 DEBUG audiobasesink gstaudiobasesink.c:2138:gst_audio_base_sink_render:<alsasink0> rendering at 0 1151/1151
0:00:00.069632000 6832 0xaaaacdc460a0 DEBUG audiobasesink gstaudiobasesink.c:2150:gst_audio_base_sink_render:<alsasink0> wrote 1151 of 1151
0:00:00.069659875 6832 0xaaaacdc460a0 DEBUG audiobasesink gstaudiobasesink.c:2181:gst_audio_base_sink_render:<alsasink0> next sample expected at 1151
The same happens if I play a flac file using pipeline:
gst-launch-1.0 uridecodebin uri="file:///tmp/audio.flac" ! audioconvert ! alsasink
Log:
0:00:00.081562125 16756 0xffff90066c50 DEBUG audiobasesink gstaudiobasesink.c:1934:gst_audio_base_sink_render:<alsasink0> sync-offset +0:00:00.000000000, render-delay 0:00:00.000000000, ts-offset +0:00:00.000000000
0:00:00.081596250 16756 0xffff90066c50 DEBUG audiobasesink gstaudiobasesink.c:1997:gst_audio_base_sink_render:<alsasink0> running: start 0:00:00.000000000 - stop 0:00:00.085333333
0:00:00.081631250 16756 0xffff90066c50 DEBUG audiobasesink gstaudiobasesink.c:2039:gst_audio_base_sink_render:<alsasink0> final timestamps: start 0:00:00.000000000 - stop 0:00:00.085333333
0:00:00.081656000 16756 0xffff90066c50 DEBUG audiobasesink gstaudiobasesink.c:2080:gst_audio_base_sink_render:<alsasink0> Clipped start: 4095/4096 samples
0:00:00.081675000 16756 0xffff90066c50 DEBUG audiobasesink gstaudiobasesink.c:2103:gst_audio_base_sink_render:<alsasink0> resync after discont/resync
0:00:00.081698750 16756 0xffff90066c50 DEBUG audiobasesink gstaudiobasesink.c:2138:gst_audio_base_sink_render:<alsasink0> rendering at 0 4095/4095
0:00:00.081749875 16756 0xffff90066c50 DEBUG audiobasesink gstaudiobasesink.c:2150:gst_audio_base_sink_render:<alsasink0> wrote 4095 of 4095
0:00:00.081773875 16756 0xffff90066c50 DEBUG audiobasesink gstaudiobasesink.c:2181:gst_audio_base_sink_render:<alsasink0> next sample expected at 4095
I think the problem causes converting samples to time and back cutting off the fractional part.