[BUG] byt media pipeline produces distortion with 44.1kHz to 48kHz conversion #1482
Description
Describe the bug
playback of 44.1kHz files to byt media pipe (hw:0,1) produces distortion. SRC in this case reads/writes with alternating frame count. Not observable in apl, so suspect dw-dma, even more copy_one_shot in host.c.
To Reproduce
playback 44.1kHz file to byt media pipe. You might need to change byt media pipe params in topology to same as in apl media pipe topology. Without this change you will get 8x speed from media pipe (which should be also debugged).
Reproduction Rate
Always.
Expected behavior
Clean sound
Impact
showstopper
Environment
- kernel:latest, fw:latest
- topology: sof-byt-rt5682.tplg
- platform:byt
- Reproducibility Rate. Always
Screenshots or console output
We have gaps in about every 1000-1200 samples
Activity
lgirdwood commentedon May 29, 2019
@juimonen can you confirm compiler used. Iirc SRC will use HiFi2EP intrinsics on BYT whilst it uses HIFI3 on APL.
juimonen commentedon May 29, 2019
@lgirdwood I'm using gcc here. this really seems like a buffer wrap issue etc. to me the discontinuity seems to coincide quite nicely with host split dma transfer but can't be sure. I think SRC calculation issue would produce much worse results...
singalsu commentedon May 29, 2019
@lgirdwood Good point, need the information.
There's the thing that the SRC with HiFiEP intrinsics is not yet fixed for timer based scheduling (at that time no xtensa built testbench, no device to test it a while ago - now I can at least test with device again so I should do it).
SRC on BYT should work with gcc build but not with xt-xcc build. I updated only the HiFi3 intrinsincs version with previous update.
singalsu commentedon May 29, 2019
@juimonen Thanks, then it's not the non-updated HiFiEP intrinsics issue.
juimonen commentedon May 29, 2019
btw there's little bit similar issue @singalsu found on 0,0 device:
#1487
juimonen commentedon May 29, 2019
you need #1489 even to try this in byt
juimonen commentedon May 31, 2019
@tlauda you have any "quick" cure for this? I'm not sure I'm interpreting correctly but is this like "dma_copy_one_shot" always copying the same fixed amount of data and not taking into account the actual needed data size?
tlauda commentedon May 31, 2019
@juimonen Yes, but it was always like this. The question is, if this has ever worked for BYT?
juimonen commentedon May 31, 2019
@tlauda hmm I'm quite new with byt, so not sure. It was also only recently that the SRC coefficients we're "downscaled" to be able to run without xruns with gcc compilation. Can't we just set the transfer size and start position in copy_one_shot? I think the dma callback at least should handle buffer wraps etc.
tlauda commentedon May 31, 2019
@juimonen It's not so easy to do, but of course can be accomplished. I haven't touched it, since I don't have any BYT platforms.
juimonen commentedon May 31, 2019
@singalsu so has this ever worked for youin byt? I think you we're using xt-xcc compilation and running src?
singalsu commentedon May 31, 2019
@juimonen The media pipeline worked a long time ago in BYT but it suffered from same regular glitches as the low latency pipe prior to SOF 1.1. So, it's very long time ago since it last worked. It stopped to work in SOF 1.1 I recall.
I've kept the SRC relaxed always for gcc so both versions have executed in real-time in BYT. I'm myself building & testing stuff nearly always with gcc.
juimonen commentedon May 31, 2019
@singalsu @tlauda so am I interpreting this correctly that this has never worked correctly in byt with dw-dma?