Baytrail: sound output is garbled with beating noise

[plbossart]

I seriously question the results of the SOF CI and platform owners.

on Baytrail, a simple listening test on Asus T100 shows the audio is just corrupted, with beating noises and frequency shifts. This is just unacceptable, sorry, SOF is just complete garbage on all legacy platforms at this point. it's embarrassing to be that bad.

firmware 6eb79af
kernel 35d7759

[fredoh9]

I have a Baytrail MinnowBoard(MB) i can take a look at.

[plbossart]

there's been some issues before like this with DMA pointers being in the weeds, can you try and grab the SSP signals with a LogicPro, then export the values in an .csv file. It's the best way to see if the samples play in sequence.

[fredoh9]

As i have only MB nocodec mode, i wanted to try to use loopback first but recording path has only silence. Not sure it was working before.
I need to check i can borrow LogicPro.

[juimonen]

@plbossart @fredoh9 is this still valid? I see other people and QA reporting that sound is ok, but there's timeout error with second playback... I also see this second playback issue in my logs, but the thing is that I have also crap sound, but now it seems that actually my hw is borked. I'm just confused about mixed reports here...

[wenqingfu]

@Jiangxinx reported that he cannot reproduce this issue on MinnowBoard+RT5651, see thesofproject/sof#1451 (comment)

[juimonen]

@plbossart I got the mb+rt5682 running. Well, sound is personally to me little different than hifiberry+up2, more high end emphasis at least. However I can't hear any obvious flaws, attached full scale sine sweep playback through mb+rt5682 and recording with my desktop.

[juimonen]

sweep_mb_rt5682.zip

[plbossart]

On 5/24/19 2:08 AM, juimonen wrote: @plbossart <https://github.com/plbossart> I got the mb+rt5682 running. Well, sound is personally to me little different than hifiberry+up2, more high end emphasis at least. However I can't hear any obvious flaws, attached full scale sine sweep playback through mb+rt5682 and recording with my desktop.

can you share kernel+firmware SHA1, I'll retry.

[juimonen]

@plbossart I think I was running it with several kernels like:
4d1fc20
c671681
0f3e63c
for me the top most was topic/sof-dev head (might have changed...)
I also used your latest broonie PR.

for fw I used like:
56b8776
which i think is master, but I also used some other
versions including revert commit of dw-dma from Guennadi:
(1da3907)

So I would say just use latest/greatest from both. I can also
test the versions you find problems with. Sorry I can't be more
specific...

[plbossart]

No change on my side on ASUS T100TA (rt5640)
The sine wave looks really bad and my theory that the samples are played in the wrong order is likely still true.

sine-asust100.wav.gz

[plbossart]

binary used, @juimonen can you try to see if we might have a compilation issue?

sof-byt.ri.gz

[plbossart]

Things work fine with the SST driver so it's not my device which is broken!

sine-asust100-sst.wav.gz

[plbossart]

firmware a26c51a
kernel 072cf06

[juimonen]

@plbossart your binary works fine with my setup...

[juimonen]

I compiled this from scratch:
kernel: 924347d (1 commit ahead of yours)
kernel config: config-daily-20190527.txt
fw: a26c51a
tplg: sof-byt-rt5682.tplg

Again I can play fine in mb+rt5682... I'm puzzled what could be the issue with your t100

[juimonen]

@plbossart when playing in byt to hw0,1 (media pipeline with src) I get funny 8x speed effect. I can fix it with changing the pipe parameters to same as apl media pipe has (0,4 in apl/up2). However then I get buzzing effect with 44.1->48. 48->48 to 0,i in byt is clean. So I can just guess that there's some issue with dw-dma and 44.1 alternating frame sizes. Will try to debug it further. however as said before hw0,0 playback is clean for me in byt.

[plbossart]

@juimonen that helps progress even if we haven't root-caused the issue.

it's not the topology file (same), not the firmware file (no difference), not the platform driver. So it's got to be codec driver or machine driver (I have the same issue with rt5645 on a CHT device). Can you try and see if there is any Asus T100 left in Espoo? Or are there any rt5651 devices left?

Also do you use the MCLK or not on the rt5682?

[singalsu]

On my Asus T100 the 16 bit playback is clean and OK. 24 bit and 32 bit content playback makes rattle (several times per second - I'll do a capture example and post the wavs and screenshots).

This is with low latency pipeline. Media pipeline is complete garbage with >2x speedup in playback time with 16 bit content. With 24 and 32 bit content the media pipeline fails immediately without anything played.

[juimonen]

@plbossart what format are you using for playback?

So currently we have several issues found:

1. pcm hw:0,0 is good with 16 bit playback
2. pcm hw:0,0 is not good with s24/s32 playback (@singalsu reported above, I confirmed)
3. pcm hw:0,1 is not running at all or huge speed up audio
   3.1 there's fix to make src to work: topology: add more buffering to media pipe after src sof#1478
   3.2 to get rid of "speed metal" effect you need to copy apl media pipe params to byt (no PR yet)
4. After 3.1 & 3.2 hw:0,1 48khz is clean, but 44.1 conversion has ripple

So to sum up:

1. something strange in 0,0 with s24/s32, this is new thing, has to be debugged
2. 0,1 media pipe need several fixes, after fixes has still rattling with 44.1kHz

btw, me and @singalsu have quite uniform results in mb/rt5682 and t100.

[singalsu]

Here's my recordings from T100.
t100_wavs.zip

And plots of seen glitches (s16 clean, s24 and s32 format have similar issue)

The glitches seem to be 1 ms long copies of previous audio, from about 20 ms ago. The glitches happen about every 32 ms.

[singalsu]

One more picture from a sound editor:

[juimonen]

@plbossart I made 2 issues:
thesofproject/sof#1482
thesofproject/sof#1487

These seems to be quite the same with me and @singalsu in mb/rt5682 and t100.
So we haven't been yet able to produce similar waveform as you...?
These both seem to be "buffer wrap" issues, but yours looks more like harmonic distortion etc.

[singalsu]

@plbossart Could you try with this chirp. The corruptions are better visible in low frequency sine wave. Though your clip sounded like totally messed up and different to my T100 so not sure if this would reveal anything.

chirp_20_20k_20s_log.wav.gz

[plbossart]

When I play a saw-tooth pattern on a MinnowBoard and grab the results with Logic Pro, I clearly see a discontinuity and as usual it's a step of 96 samples. Please redo the measurements by checking the signals on the connector first.
aplay -Dhw:0,0 -c2 -r48000 -f dat cnt_1024_left.pcm
cnt_1024_left.pcm.gz

ssp-gap.xlsx

[plbossart]

I have the issue issue on Asus 100 TA (rt5640), Asus T100HA (rt5645) and the Dialog DA7213 test board. All of them work fine with the closed-source firmware, none of them work with SOF.

[juimonen]

@plbossart I'll try again tomorrow in the office. btw did you have this thesofproject/sof#1514 in your fw code? it fixed the s24/s32 playback for me...

[plbossart]

@juimonen yes this is with the latest firmware, but I play in S16_LE on hw:0,0 so your changes probably don't matter.

[singalsu]

Here's my analog recording from the Asus T100 (model T100TA-DK024H) with Pierre's file played with command:

aplay -Dhw:0,0 -c2 -r48000 -f dat cnt_1024_left.pcm
The recording looks clean to me, no such repeating discontinuity as in above logic analyzer screenshot or in the spreadsheet data. I have fresh kernel, topology (sof-byt-rt5640.tplg), firmware fetched and built today.

rec_cnt_1024_left_pcm.wav.gz

[singalsu]

Continued... if I had this corruption (plot made from Pierre's spreadsheet) it would show up well in the analog waveform too.

[juimonen]

@plbossart I'm also recording from analog output of codec and drawing from recorded wav-file. This kind of gaps should show up through the codec... I'm puzzled what you have there...

[plbossart]

I don't have an answer but can you please try and look at the connector level? You are using different codecs in different configurations so we don't have a common environment to test. The connector is the only common part and it should be the first test we do.

[juimonen]

@plbossart you are probably busy with other stuff, but is this still valid? If you have spare time to re-check with your setup... I think there has been some changes to byt ipc and other parts of the code.

[plbossart]

@juimonen ack, i'll retry tomorrow.

[plbossart]

not reproducible on ASUS T100 HAN (CHT), but PulseAudio speaker test generates audible underflows

[plbossart]

Not reproducible on Asus T100 TA (BYT) either. I wasn't able to check Pulseaudio, @juimonen can you give it a try with the UI speaker test?

[juimonen]

@plbossart in byt-mb aplay works fine but with pulseaudio I have similar issues than you, so quite nasty gaps in audio. Manually running pulseaudio doesn't spit out any xruns, also fw logger seems clean.
With aplay I also get like small part of the audio repeated in the end when I cut the playback with ctrl-c... don't know if it is related, but seems this is not underrun, but some error in reporting the position or writing to audio buffer.

[juimonen]

btw, if I play with "paplay -vvvv" (verbose mode) the audio is clean (!?). And I see from dmesg position reporting that there's some difference. So with -vvv the buffer fill sizes are calculated somehow differently. Now the question is, why pulse "default" playback is not working, pulse or sof issue?

[plbossart]

it's definitively SOF, this doesn't happen with the legacy driver. I'll file another issue on this to avoid misunderstandings.

[plbossart]

follow-up on #1285