[BUG] byt media pipeline produces distortion with 44.1kHz to 48kHz conversion

[juimonen]

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

1. kernel:latest, fw:latest
2. topology: sof-byt-rt5682.tplg
3. platform:byt
4. Reproducibility Rate. Always

Screenshots or console output
We have gaps in about every 1000-1200 samples

[lgirdwood]

@juimonen can you confirm compiler used. Iirc SRC will use HiFi2EP intrinsics on BYT whilst it uses HIFI3 on APL.

[juimonen]

@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]

@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]

@juimonen Thanks, then it's not the non-updated HiFiEP intrinsics issue.

[juimonen]

btw there's little bit similar issue @singalsu found on 0,0 device:
#1487

[juimonen]

you need #1489 even to try this in byt

[juimonen]

@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]

@juimonen Yes, but it was always like this. The question is, if this has ever worked for BYT?

[juimonen]

@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]

@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]

@singalsu so has this ever worked for youin byt? I think you we're using xt-xcc compilation and running src?

[singalsu]

@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]

@singalsu @tlauda so am I interpreting this correctly that this has never worked correctly in byt with dw-dma?