Repository navigation
Get noise when aplay on BYT-rt5651 platform. #1208
Description
Summary:
Hear the wrong frequency sound when aplay correct params on BYT-rt5651 platform.
Dmesg and sof-logger have no obvious error trace.
Step:
1.aplay -Dhw:0,0 -c2 -r48000 -fS16_LE Music/sine_48k_16bit_10s_stereo_l5_r2.wav -vv -i
Output:
Playing WAVE 'Music/sine_48k_16bit_10s_stereo_l5_r2.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
Hardware PCM card 0 'sof-bytcr-rt5651' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 48000
exact rate : 48000 (48000/1)
msbits : 16
buffer_size : 16320
period_size : 4032
period_time : 84000
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 4032
period_event : 0
start_threshold : 16320
stop_threshold : 16320
silence_threshold: 0
silence_size : 0
boundary : 9187343239835811840
appl_ptr : 0
hw_ptr : 0
#########################+ | 48%
Env:
sof master: 052942c
kernel sof-dev: f304b5c
tplg: sof-byt-rt5651.tplg
Recorded sine file
Recorded_sine.zip
:
Original sine file:
Original_sine.zip
Activity
tlauda commentedon Apr 1, 2019
@Jiangxinx Please always add logs. There is no point in creating an issue without dmesg and FW logs. What is the repro ratio?
lgirdwood commentedon Apr 1, 2019
@Jiangxinx L/R look similarly corrupted. @bardliao could this be codec misconfiguration ?
bardliao commentedon Apr 1, 2019
@lgirdwood Yes, codec can copy the data from one channel to the other channel or mix L/R together and output to both L/R channels. @Jiangxinx Could you use LR_48k.zip to see if the L/R channel are output separated or not?
Regarding the frequency issue, could you measure the physical frequency of LRCK, BCLK, and MCLK?
Also, could you add
#define DEBUGin rt5651.c and attach the dmesg output here?singalsu commentedon Apr 2, 2019
@Jiangxinx When doing error recordings please use low enough recording gain so that recording is not clipped to full scale as this is. Also mp3 encoding is not a recommended format. It's a lossy coding that does not preserve the waveform shape. Please use flac or wav format.
But I think the mp3 is representative enough to say that the effect that is heard is not wrong frequency (e.g. pitch shift perceived) but quite bad corruption. If the used format would be lossless e.g. buffer discontinuity errors would be visible. But mp3 format blurs such details.
Jiangxinx commentedon Apr 2, 2019
@bardliao I tried LR_48K using the daily version ofter enable DEBUG in rt5651.c, L/R channel are not separated and can hear the wrong frequency sound when aplay.
Dmesg after enable DEBUG:
Log file:
dmesg.log
LRCK:
BCLK:
MCLK:
bardliao commentedon Apr 2, 2019
@Jiangxinx All LRCK/BCLK/MCLK looks the same? And the frequency is very low. Could you double check it?
Regarding the dmesg, there are too many sof logs. Could you remove
ccflags-y += -DDEBUGfrom linux/sound/soc/sof/Makefile and get the dmesg again?Thanks.
Jiangxinx commentedon Apr 2, 2019
@bardliao Retested the aplay function after removed ccflags-y += -DDEBUG, and attach dmesg info below.By the way,i have checked the LRCK/BCLK/MCLK again, and got the same results.
Git diff:
dmesg:
Log file:
dmesg.log
singalsu commentedon Apr 2, 2019
@Jiangxinx Are the oscilloscope pictures above just mains interference, 50 Hz?
lgirdwood commentedon Apr 2, 2019
Yep, and given LRCLK, BCLK and MCLK are all 50Hz means @Jiangxinx your scope is not correctly connected to the signals and grounded. Please also make sure the playback is enabled and running too (since scopes will "autodetect" the mains if nothing else is propagating).
juimonen commentedon Apr 2, 2019
@lgirdwood don't now about scope grounding, but I just got mb&rt5651 playing first time and the audio is complete bogus. it is like really low frequency brittle or anyway something very difficult to describe. I can switch between hp and speaker so I think my alsamixer setup is at least somehow correct.
bardliao commentedon Apr 2, 2019
@lgirdwood
Does it mean there are something wrong on FW?
lgirdwood commentedon Apr 2, 2019
@bardliao yes, also something wrong with FW here too or driver here too.
1 remaining item
juimonen commentedon Apr 3, 2019
@Jiangxinx did you update SW in between the tests? I don't get why removing DDEBUG would cause error. I mean your first log doesn't contain error and I guess the streaming should not even start if you get this...?
juimonen commentedon Apr 3, 2019
@Jiangxinx @bardliao I have the same error, but it's coming always after streaming when "stop" is triggered. For e.g. I have a experimental pm setup where I'm loading topology always from scratch when streaming starts. So in my opinion this error should not be the cause of corrupted sound...
bardliao commentedon Apr 3, 2019
@juimonen I think we didn't see the error in the first log is that there are too many logs and it exceeds the buffer of dmesg. So we can only see the recent log.
juimonen commentedon Apr 3, 2019
@bardliao yes understood it also later... would it be possible for you to check we are setting the codec parameters ok? Otherwise I can't think of anything else than the dma to dsp is different in this platform and/or we are copying some total garbage to codec.
juimonen commentedon Apr 3, 2019
@bardliao sorry to confuse you, I think there's no issue with the codec. I had myself some issues with the build system (I think I was building some garbage firmware) see my comments in: #1215
[-]Hear the wrong frequency sound when aplay correct params on BYT-rt5651 platform.[/-][+]Noise when aplay correct params on BYT-rt5651 platform.[/+][-]Noise when aplay correct params on BYT-rt5651 platform.[/-][+]Get noise when aplay on BYT-rt5651 platform.[/+]bardliao commentedon Apr 4, 2019
@juimonen No problem. Hope it can be fixed soon :)
wenqingfu commentedon Apr 4, 2019
@juimonen , is this a duplicate of #1215?
juimonen commentedon Apr 4, 2019
@wenqingfu not 100% sure but really looks like it.
wenqingfu commentedon Apr 4, 2019
mark as duplicate of #1215 . @tlauda @juimonen please move covnversation to #1215. @Jiangxinx please provide testing support to #1215 and reopen this bug if you can still reproduce it after #1215 is fixed.