You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Broken playback on Up^2 with HifiBerry with SRC topology #1147
Playback on Up^2 with a HifiBerry codec and the sof-apl-pcm512x topology currently produces strongly metallic sound. Bisection and a manual verification identified aebe3ce from @tlauda as the offending commit.
@tlauda Actually there is no error. If you can hear the playback sound. It will be full of noise. @xun2z Could you upload the wav recorded by you? I think this is the same situation we have found on byt_rt5651/5682
@ranj063 On APL we are using Host DMA, so the flow is a little bit different. We don't observe any playback issues on APL, so that's why I'm asking if it's HDMI or SSP and if there is any bit conversion in between.
I think this is different from #1107 since that one also mentions a different commit as the culprit. Yes, SSP. The audio format is "Float 32 bit Little Endian, Rate 8000 Hz, Stereo" Log attached, I added a couple of empty lines between initialisation and playback. metal.txt
@ranj063 it turned out I was using the topology with the src, sorry for confusion. And it used to work until that commit. I tried with the "no src" topology and it's working now. Is there any reason why the "src" topology shouldn't work for playback?
@xiulipan The noise can be eliminated be reducing the volume, @singalsu thinks, there might be an off-by-one error (in a volume configuration?) somewhere
@tlauda I'm at the moment updating SRC work with current pipeline. It supports circular buffers already but the processing size is pre-determined. All the sample rates combinations are impacted - even 48 -> 48 kHz pass.
@xiulipan@lyakh I've checked that volume nor SRC does not overflow. The overflow happens inside HifiBerry DAC+ PCM512x codec. It looks like DAC internal signal processing issue or a registers programming bug in ASoC driver. It can be avoided by setting gain "Digital" to -1 dB. With 0 dB the full scale peaks in music can do what's seen in this issue #619 that was filed by @juimonen.
There's also a recorded screenshot of the overflow happening.
@singalsu Processing size shouldn't be a problem as long as it isn't 0, because that will trigger fail in the following components e.g. volume. But since SRC can sometimes produce 0 samples, we need the mechanism for stopping pipeline processing in that situation. Returning PPL_STATUS_PATH_STOP from src_copy will handle the stopping part, but render ppl scheduled on DMA won't get rescheduled, since we haven't yet started the DAI. We need to carefully think about the right approach and implementation.
As long as DAI in playback doesn't starve (xrun), returning zero samples in other pipeline should not be an error. SRC can output 0 samples in complex 44.1 <-> 48 kHz family conversions especially in the beginning when the internal buffers are not filled enough.
When converting within 48 kHz family it can operate with constant number of frames every copy.
Yes, agree, but it doesn't make sense to perform copy on the components after SRC, if it produced 0 samples during preload phase. We would output zeroes anyway and also end up with mixed up DMA pointers as it was before. In the end it comes to the right implementation. I think that @bkokoszx is working on such pipeline flow, where components due to the different processing frames can produce even 0 bytes.
Looks like I was getting that corrupted sound with pulseaudio running and a few days old kernel with CONFIG_SND_SOC_SOF_DEBUG_FORCE_IPC_POSITION set. Without pulseaudio the audio quality seemed ok, although on maximum volume it was difficult to be sure. I then replaced the kernel with a newer one without that option set, and it was able to work properly also with pulseaudio enabled. However, then I tried using the SRC topology and this time I got no sound at all and I've got a DSP panic. But I have to double-check that, it's possible that I have some incompatible parts installed... And I'll also have to check a current kernel with "FORCE_IPC_POSITION" enabled, since IIRC it should be fixed by now.
Activity
tlauda commentedon Mar 19, 2019
@lyakh Can you upload FW logs? Is it SSP or HDMI playback? What format of the stream and what format of the DAI?
xiulipan commentedon Mar 19, 2019
@tlauda Actually there is no error. If you can hear the playback sound. It will be full of noise.
@xun2z Could you upload the wav recorded by you? I think this is the same situation we have found on byt_rt5651/5682
ranj063 commentedon Mar 19, 2019
@lyakh @tlauda I think this is the same issue as #1107
on the Up2
tlauda commentedon Mar 19, 2019
@ranj063 On APL we are using Host DMA, so the flow is a little bit different. We don't observe any playback issues on APL, so that's why I'm asking if it's HDMI or SSP and if there is any bit conversion in between.
ranj063 commentedon Mar 19, 2019
@tlauda since Guennadi mentions the hifiberry I have to assume it is the SSP. For HDMI the hifiberry has no role to play.
ranj063 commentedon Mar 19, 2019
@xiulipan @lyakh @tlauda I checked with the latest master (commit: 6e88bdf) and there is no noise with the hifiberry.
But #1107 still remains.
lyakh commentedon Mar 19, 2019
I think this is different from #1107 since that one also mentions a different commit as the culprit. Yes, SSP. The audio format is "Float 32 bit Little Endian, Rate 8000 Hz, Stereo" Log attached, I added a couple of empty lines between initialisation and playback.
metal.txt
lyakh commentedon Mar 19, 2019
@ranj063 I just double-checked with the same HEAD commit and the distortion is still there. Attaching my .config.
up2-config.txt
tlauda commentedon Mar 19, 2019
@lyakh 8 kHz means that the SSP is also set to 8 kHz or is there SRC in the pipeline?
ranj063 commentedon Mar 19, 2019
@lyakh what topology are you using?
sof-apl-pcm512x.tplg without the SRC works without noise at my end.
lyakh commentedon Mar 19, 2019
@ranj063 it turned out I was using the topology with the src, sorry for confusion. And it used to work until that commit. I tried with the "no src" topology and it's working now. Is there any reason why the "src" topology shouldn't work for playback?
12 remaining items
xiulipan commentedon Mar 29, 2019
@lyakh
I mean there is no error log or error dmesg.
So you mean you have all thing run right, but get noise when play?
lyakh commentedon Mar 29, 2019
@xiulipan The noise can be eliminated be reducing the volume, @singalsu thinks, there might be an off-by-one error (in a volume configuration?) somewhere
xiulipan commentedon Mar 29, 2019
@lyakh
Maybe the volume copy function need some check.
singalsu commentedon Mar 29, 2019
@tlauda I'm at the moment updating SRC work with current pipeline. It supports circular buffers already but the processing size is pre-determined. All the sample rates combinations are impacted - even 48 -> 48 kHz pass.
singalsu commentedon Mar 29, 2019
@xiulipan @lyakh I've checked that volume nor SRC does not overflow. The overflow happens inside HifiBerry DAC+ PCM512x codec. It looks like DAC internal signal processing issue or a registers programming bug in ASoC driver. It can be avoided by setting gain "Digital" to -1 dB. With 0 dB the full scale peaks in music can do what's seen in this issue #619 that was filed by @juimonen.
There's also a recorded screenshot of the overflow happening.
tlauda commentedon Mar 29, 2019
@singalsu Processing size shouldn't be a problem as long as it isn't 0, because that will trigger fail in the following components e.g. volume. But since SRC can sometimes produce 0 samples, we need the mechanism for stopping pipeline processing in that situation. Returning PPL_STATUS_PATH_STOP from src_copy will handle the stopping part, but render ppl scheduled on DMA won't get rescheduled, since we haven't yet started the DAI. We need to carefully think about the right approach and implementation.
singalsu commentedon Mar 29, 2019
As long as DAI in playback doesn't starve (xrun), returning zero samples in other pipeline should not be an error. SRC can output 0 samples in complex 44.1 <-> 48 kHz family conversions especially in the beginning when the internal buffers are not filled enough.
When converting within 48 kHz family it can operate with constant number of frames every copy.
tlauda commentedon Mar 29, 2019
Yes, agree, but it doesn't make sense to perform copy on the components after SRC, if it produced 0 samples during preload phase. We would output zeroes anyway and also end up with mixed up DMA pointers as it was before. In the end it comes to the right implementation. I think that @bkokoszx is working on such pipeline flow, where components due to the different processing frames can produce even 0 bytes.
lyakh commentedon Mar 29, 2019
Looks like I was getting that corrupted sound with pulseaudio running and a few days old kernel with CONFIG_SND_SOC_SOF_DEBUG_FORCE_IPC_POSITION set. Without pulseaudio the audio quality seemed ok, although on maximum volume it was difficult to be sure. I then replaced the kernel with a newer one without that option set, and it was able to work properly also with pulseaudio enabled. However, then I tried using the SRC topology and this time I got no sound at all and I've got a DSP panic. But I have to double-check that, it's possible that I have some incompatible parts installed... And I'll also have to check a current kernel with "FORCE_IPC_POSITION" enabled, since IIRC it should be fixed by now.
lyakh commentedon Mar 29, 2019
I rebuilt both the kernel modules and the firmware, no panic this time, but the sound is bad. Attaching the result.
corrupted-sound.tar.gz
singalsu commentedon Mar 29, 2019
@lyakh Yep, that's the issue I'm trying to fix now. Sounds the same in my tests.
singalsu commentedon Apr 3, 2019
PR #1219 fixes for me the playback quality with SRC. So far I've tested only with UP2.
singalsu commentedon Apr 5, 2019
@lyakh Merged now, can you please check there too.
singalsu commentedon Apr 8, 2019
Closing.