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
@tlauda it looks like we've got another problem with the sof byt topology. I cant start playback on the media pipeline at all. The recent changes to the pipeline commands are probably responsible for this. Do you have a BYT set up? This is the only working topology we have to test out all your recent changes.
@ranj063 I assume the other pipelines work ? Can you provide the logs for the failing media pipeline. @keqiaozhang can you try some different pipelines as part of QA, this is a big feature update so we need to make sure we give it a broad test with as many different topologies we can. Thanks.
@lgirdwood the other playback pipeline works. I think the reason might be that in the FW today we dont propagate trigger from another pipeline. I will post the logs soon
@tlauda I've already tried with #1136 and it didnt fix the issue.
stream format: S16_LE
DAI format: S24_4LE
what I noticed was with the above combination, playback is noisy. But if the stream format is S24_4LE as well, there is no noise, which leads me to think that maybe there's something off with the volume conversion maybe? I'm not sure though as I lookedinto the code and everything looks good.
changed the title [-]Mixer variable data copy causes underrun during playback on BYT with RT5651[/-][+]Noisy playback on BYT with RT5651[/+]on Mar 18, 2019
@ranj063 this is the situation I talked to you about byt-rt5651 tplg.
sof-byt-rt5651 involves a very complex topology included mixer. And we have no test about that component yet. So in CI we use some single volume test topology.
I will check if this is some shared problem in all mixer component or some single problem with BYT or RT5651.
@ranj063
Checked with byt_rt5682/5682 with simple host -> volume -> dai pipeline. I now believe #1147 is a duplicate of this. We need to check the whole pipeline, not only BYT
Activity
lgirdwood commentedon Mar 11, 2019
@ranj063 @tlauda I'm guessing this will be fixed when the variable dai/host PR is merged (pending CI and QA atm).
tlauda commentedon Mar 11, 2019
@lgirdwood I guess so, BYT is now passing on my PR. But I'm still confused why changes in mixer component affected simple volume pipelines?
ranj063 commentedon Mar 11, 2019
@tlauda BYT topology is not a simple pipeline. It has a media playback pipeline and low latency playback connected at the mixer.
tlauda commentedon Mar 11, 2019
@ranj063 Could you check with the current master? I've fixed my host/dai var copy and CI for BYT passed.
ranj063 commentedon Mar 11, 2019
@tlauda unfotunately no. We've still got the same problem
ranj063 commentedon Mar 11, 2019
@tlauda it looks like we've got another problem with the sof byt topology. I cant start playback on the media pipeline at all. The recent changes to the pipeline commands are probably responsible for this. Do you have a BYT set up? This is the only working topology we have to test out all your recent changes.
lgirdwood commentedon Mar 11, 2019
@ranj063 I assume the other pipelines work ? Can you provide the logs for the failing media pipeline. @keqiaozhang can you try some different pipelines as part of QA, this is a big feature update so we need to make sure we give it a broad test with as many different topologies we can. Thanks.
ranj063 commentedon Mar 11, 2019
@lgirdwood the other playback pipeline works. I think the reason might be that in the FW today we dont propagate trigger from another pipeline. I will post the logs soon
tlauda commentedon Mar 15, 2019
@ranj063 Can you provide log with verbose traces and not working playback (the one without a mixer).
ranj063 commentedon Mar 15, 2019
@tlauda both the playback pipelines go through the mixer in the BYT topology. not sure about this ask?
lgirdwood commentedon Mar 15, 2019
@ranj063 I think @tlauda just needs the verbose traces when it fails via mixer playback.
ranj063 commentedon Mar 15, 2019
@tlauda @lgirdwood here're the logs with verbose trace enabled before starting playback on PCM 1 and after starting playback
byt_logger_pre_playback.txt
byt_logger_post_playback.txt
3 remaining items
ranj063 commentedon Mar 18, 2019
@tlauda I've already tried with #1136 and it didnt fix the issue.
stream format: S16_LE
DAI format: S24_4LE
what I noticed was with the above combination, playback is noisy. But if the stream format is S24_4LE as well, there is no noise, which leads me to think that maybe there's something off with the volume conversion maybe? I'm not sure though as I lookedinto the code and everything looks good.
[-]Mixer variable data copy causes underrun during playback on BYT with RT5651[/-][+]Noisy playback on BYT with RT5651[/+]ranj063 commentedon Mar 18, 2019
I've edited the title because I dont think it has anything to do with just variable copy on the mixer
lgirdwood commentedon Mar 18, 2019
Adding @singalsu.
@ranj063 I guess you have tried gcc and xt-xcc ?
ranj063 commentedon Mar 18, 2019
@lgirdwood xt-xcc compilation for BYT is broken. Now might be the best time to fix it. Let me work on it today
xiulipan commentedon Mar 19, 2019
@ranj063 this is the situation I talked to you about byt-rt5651 tplg.
sof-byt-rt5651 involves a very complex topology included mixer. And we have no test about that component yet. So in CI we use some single volume test topology.
I will check if this is some shared problem in all mixer component or some single problem with BYT or RT5651.
ranj063 commentedon Mar 19, 2019
@xiulipan maybe sof-byt-rt5651 is not ready for CI yet but I have the issue even with a simple volume playback pipeline on BYT
tlauda commentedon Mar 19, 2019
@ranj063 Could you check with PRs #1144 and #1136?
xiulipan commentedon Mar 19, 2019
@ranj063
Checked with byt_rt5682/5682 with simple
host -> volume -> daipipeline. I now believe #1147 is a duplicate of this. We need to check the whole pipeline, not only BYTranj063 commentedon Mar 19, 2019
@tlauda this is the commit that causes the noise on the minnowboard
407be96 dai: change flow of component copy
lyakh commentedon Mar 19, 2019
#1147 isn't quite the duplicate, but it's the same commit, that's causing them both
tlauda commentedon Mar 21, 2019
@ranj063 Please verify after applying following patches: #1136, #1159, #1160 and #1162. @xiulipan confirmed, that sound is now clean.
ranj063 commentedon Mar 21, 2019
@tlauda confirmed fixed with the above PR's that are merged into master already.