Repository navigation
Baytrail: sound output is garbled with beating noise #933
Description
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.
Activity
fredoh9 commentedon May 13, 2019
I have a Baytrail MinnowBoard(MB) i can take a look at.
plbossart commentedon May 13, 2019
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 commentedon May 14, 2019
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 commentedon May 17, 2019
@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 commentedon May 21, 2019
@Jiangxinx reported that he cannot reproduce this issue on MinnowBoard+RT5651, see thesofproject/sof#1451 (comment)
juimonen commentedon May 24, 2019
@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 commentedon May 24, 2019
sweep_mb_rt5682.zip
plbossart commentedon May 24, 2019
juimonen commentedon May 24, 2019
@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 commentedon May 24, 2019
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 commentedon May 24, 2019
binary used, @juimonen can you try to see if we might have a compilation issue?
sof-byt.ri.gz
14 remaining items
juimonen commentedon Jun 4, 2019
@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 commentedon Jun 4, 2019
@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 commentedon Jun 6, 2019
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.pcmThe 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 commentedon Jun 6, 2019
Continued... if I had this corruption (plot made from Pierre's spreadsheet) it would show up well in the analog waveform too.
juimonen commentedon Jun 6, 2019
@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 commentedon Jun 6, 2019
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 commentedon Aug 22, 2019
@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 commentedon Aug 22, 2019
@juimonen ack, i'll retry tomorrow.
plbossart commentedon Oct 7, 2019
not reproducible on ASUS T100 HAN (CHT), but PulseAudio speaker test generates audible underflows
plbossart commentedon Oct 7, 2019
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 commentedon Oct 8, 2019
@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 commentedon Oct 8, 2019
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 commentedon Oct 8, 2019
it's definitively SOF, this doesn't happen with the legacy driver. I'll file another issue on this to avoid misunderstandings.
plbossart commentedon Oct 8, 2019
follow-up on #1285