Repository navigation
[BUG]Glitches in beginning of playback via SRC pipe #1843
Description
Describe the bug
Especially with 48 kHz content playback to Media Playback device the first fraction of a second has discontinuities in output waveform. The effect can be heard when listening carefully.
Witht other sample rates like 32 kHz there's typically one glitch. 48 kHz has several (5).
To Reproduce
Playback of 48 kHz content to hw:0,4 device in UP^2 with default topology sof-apl-pcm512x.tplg.
Reproduction Rate
Always.
Expected behavior
Clean playback start.
Impact
It's an annoyance.
Environment
- Branch name and commit hash of 3 repositories: sof (firmware), linux (kernel driver) and soft (tools & topology).
- Name of the topology file
- Name of the platform(s) on which the bug is observed.
- Reproducibility Rate. If you can only reproduce it randomly, it’s useful to report how many times the bug has been reproduced vs. the number of attempts it’s taken to reproduce the bug.
Screenshots or console output
Activity
lgirdwood commentedon Sep 30, 2019
@singalsu I assume SRC is reading ahead ? It could just be we need to zero all SRC source buffer before we start.
tlauda commentedon Oct 11, 2019
@singalsu On BYT it looks even worse with 48 kHz:
singalsu commentedon Oct 24, 2019
My recording setup is now fixed (rt kernel, jack, from Ubuntu studio). I still get a glitch always into about 100 ms before UP2+Hifiberry playback stop with other than 48 kHz rates. FW is today's git master as well as default topology used sof-apl-pcm512x.tplg topology. This is gcc build.
Otherwise the playback looks clean. This was playback at 44.1 kHz rate and S24_LE format. The result is identical with S16_LE and S32_LE formats.
singalsu commentedon Oct 24, 2019
SRC is not exceeding what's available in source. There used to be a pre-fill in 1st copy() for conversions those cannot produce worth of 1 ms output (if that's the scheduling) in first copy() with 1 ms of input data. But it's no more used since with timer based scheduling the amounts to process are more fuzzy, can't compute in advance the need for pre-fill. Though adding some guessed pre-fill could be added if the component down-stream to SRC starves. But I don't think this is from it since this happens with easy conversions as well like 32 -> 48 kHz where SRC can output exactly the 48 frames per copy(). With easy conversions the internal block size is small so it can output e.g. 45, 48, or 51 frames while consuming 30, 32, or 34 frames (for 32 -> 48 kHz).
singalsu commentedon Oct 24, 2019
I think this bug should be closed (and a new one to be entered) if the playback on BYT has also become clean as it has been on APL.
Concerning this glitch near playback end some notes.
The glitch is still near end when playing back much longer 30s clip, the reported clip was 1s. It confirms the issue is not 900 ms from beginning as it could have also been.
The same happens if I press ctrl-c during aplay for 30s clip after about 5s time. The glitch shows up near end of recorded sine burst (did once, it was 200 ms before end).
The simpler SRC pipeline in topology sof-apl-src-pcm512x.tpl does not have this issue. The tested pipeline with glitch issue is more complex with two volume components and one mixer.
In a similar test carried out by @tlauda with test pipeline host - vol - src - vol - dai, in use case 44.1 -> 48, s24 no glitches observed.
Also the captured sine wave bust is 1.1s long when the wav clip is 1.0s long. Maybe the last 100ms is a copy of old buffers?
tlauda commentedon Oct 25, 2019
@singalsu Yes, it's clean also on BYT. Closing this one. Please create new bug.