[cml][sdw][STRA-P]: The volume of built-in audio output is low for 1-2 sec as come back from runtime-pm

[jason77-wang]

On the STRA-P (cml soundwire audio), before runtime suspend, the audio (speaker/headphone)'s output volume is correct, after it enters runtime suspend and runtime resume, the output volume is lower than before for about 1-2 seconds,then it changes back to normal.

This issue could be reproduced with sof-firmware-v1.6 and the kernel branch sof-dev-rebase. This issue could not be reproduced on MLK OLY machine (TGL soundwire audio).

[keyonjie]

@singalsu is this expected for volume ramping?

[singalsu]

@jason77-wang A recording of this issue would be really good to have. Are you able to make such? Acoustical recording is also OK.

Edit: A sine wave would be ideal content to demonstrate the issue.

[singalsu]

@keyonjie None of the defined ramps is 1-2s long, though technically it would be possible with wrong made topology.

[plbossart]

@jason77-wang are you using the same userspace components on both devices? There's really nothing specific to CML or TGL here.

[jason77-wang]

@plbossart yes, same userspace components on both devices.

@singalsu OK, will record a sound sample, since I don't have this machine, need my colleague in Taipei office to do that.

Thanks.

[lihow731]

I put the record video in blew link: The first sound effect is lower volume

[singalsu]

Yes the issue can be heard and seen (below) but please make a recording with a steady sine wave. The key presses are too much away to see the gain envelope. There's also a gain envelope in the "blip" sound clip as well so it's not good for test. This recording quality is totally sufficient, just need different test signal.

sine.zip

[keyonjie]

@aiChaoSONG @WYL-12 can you help to reproduce this with sof-firmware-v1.6 and the sof kernel sof-dev-rebase-20201201?

[aiChaoSONG]

@jason77-wang @lihow731 I test this issue with sof-firmware-v1.6 and the sof kernel sof-dev-rebase-20201201 with speaker-test -Dhw:0,2 -t wav -c 2, I can hear that the fron in front-left is a little bit low, but from the t sound in front, the volume go back to normal. after checking the waveform of front-left.wav, I find that the fron duration is about 0.2s, so I think this is a normal fade-in. could you please play a continuous sound or music to see if it is really a 1~2s low volume period and also confirm my test result? I mean the system ding may be to short for the verification.

[keyonjie]

@jason77-wang @lihow731 can you confirm the volume ramping time is actually only around 0.2s? if so, this is expected.

[singalsu]

The token SOF_TKN_VOLUME_RAMP_STEP_MS is set to 20 for 20 ms long ramp in playback topologies. If the ramp is 0.2s it's too long. The continuous sine wave recording is needed to check the ramp characteristic. Please don't use music or any UI effects sounds since they contain their own level envelope.

[singalsu]

If you don't have a sine wave clip, please use this:

sine_997hz_6db_10s_mono_16b.wav.gz

[jason77-wang]

Since I don't have the hw, I could not confirm if the ramp is 0.2s or 1~2s. Our QA filed a bug against this issue, that means the ramp on this machine is obvious longer than on other machines.

@lihow731, do you think it is 0.2s or 1~2s?

Thanks.

[lihow731]

Please watch the video that the sine-997Hz twice was played twice.

https://drive.google.com/file/d/18Q5SzKajcvzIVoXgemSyXxGuzOYRMZ3N/view?usp=sharing

[singalsu]

Thanks @lihow731 ! Here's the audio waveforms from your video. It was MPEG AAC format so not as reliable as uncompressed wav but it looks like the first ramp is 150 ms long and second 5 ms or less (AAC coding impacts, so I assume there's no ramp).

@keyonjie @aiChaoSONG Do you know which topology this device uses? The playback start ramp should be 20 ms in SOF topologies. The 150 ms seen is too long.

@lihow731 If you can check it, the used topology name can be found from console with dmesg | grep "loading topology" .

[aiChaoSONG]

@singalsu The topology used is sof-cml-rt711-rt1308-rt715.tplg, and it is the same topology as sof-icl-rt711-rt1308-rt715.tplg and is generated from sof-icl-rt711-rt1308-rt715-hdmi.m4 @lihow731 @singalsu I do a headset loopback on the headphone, below is the wave recorded via USB sound card, there is very short ramp, maybe 1 ~ 2 ms stra_loopback.zip

I also record a video on the speaker playback, there is no such long latency either, https://www.youtube.com/watch?v=FbXJqkrOPQg

I am testing with https://github.com/thesofproject/linux/tree/sof-dev-rebase-20201201 and sof-1.6, so we should use the same FW, but different kernel, I suggest to try with my kernel. sof-dev_rebased_20201201.zip

@keyonjie I also noticed that it takes about 200ms for the DSP to restore context, I am not sure is this make a different. From the video provided by @lihow731, it seem the aplay process is blocked by something for a while.

[keyonjie]

it could be the ramp (power on) time for the codec side?

[singalsu]

@aiChaoSONG The playback start ramp should be 20 ms. I wonder if the loopback was made with pulseaudio since there wasn't really any start ramp, mainly a DAC impulse response for sine wave start.

When looking at sof-cml-rt711-rt1308-rt715.conf there's some variation in playback pga's SOF_TKN_VOLUME_RAMP_STEP_MS values. I'll check from .conf that they get the correct values.

@keyonjie Yep, the codec could do this.

[singalsu]

There's a mistake in muxdemux pipeline volume tokens. Need to use the macros with pipeline IDs to make tokens unique to that volume instance. I wonder if the 250 comes from capture side where it's a normal value.

PGA1.0 is 20ms PGA3.1 is 250ms PGA6.0 is 20ms PGA7.0 is 20ms PGA8.0 is 20ms

I can do a PR to fix this today but I can't test it (don't have the device, will start my holidays in few hours and back in Jan 4th). I can attach a binary topology that could be tried on the device by copying it over over original.

(The bug severity in SOF topology is not critical in my opinion.)

[kv2019i]

Confirmed as FW topology issue, moving to sof component. It seems we lost the tags in transfers, will add them back.

[singalsu]

@lihow731 Can you please test with this topology. Check where the topology file is located and replace it with this (unzip, make a backup of original file first to restore)

cd /lib/firmware/intel
find . -name sof-cml-rt711-rt1308-rt715.tplg

sof-cml-rt711-rt1308-rt715.zip

[lihow731]

@singalsu

I tested the sof-cml-rt711-rt1308-rt715.zip, this issue still exists.

From kernel message, the ABI info: Topology: ABI 3:18:1 Kernel ABI 3:13:0 I posted the full dmesg output on https://pastebin.ubuntu.com/p/WKnsj4XVDd/ . The video: https://drive.google.com/file/d/1LOrMj9CDJQ_z8WNPR6-pFcX_8eEV7Bzr/view?usp=sharing

[mengdonglin]

@lihow731 On your CML STRA-P device, can this issue only be reproduced with built-in speaker output? Or can it also be reproduced with headset output?

[lihow731]

@mengdonglin

This issue only is reproduced with built-in speaker. This issue can not be reproduced with headset output.

[singalsu]

The patch in my opinion impacted, the start ramp is now much shorter, about 30 ms (compare to above! though should be 20) but the used MPEG audio coding may impact it. A wav capture without lossy format would be better. If there's still difference in ramp length it's caused by external amplifier, codec, etc.

[singalsu]

@lihow731 @aiChaoSONG I don't have a device like this. Do you still feel the fade-in is too long for UI beep/ping/blip like sounds? Though the gain ramp with the PR is the same as with headset so they should sound similar unless there's difference in codec/amp power-on times.

[aiChaoSONG]

@singalsu I was unable to reproduced this issue on one device in PRC, I guess it may be device specific.

[lihow731]

@aiChaoSONG This issue can be reproduced on STRA-DVT2-C7 and STRA-DVT2-C8. Could you get these SKUs? I can reproduce this issue on another platform: cyborg N 15 (CNU5-DVT1-C7). (Maybe the root cause is different)

[aiChaoSONG]

@lihow731 Some summary from my side, I cannot reproduce this issue Kernel: sof-dev-rebase-20201201, kernel deb attached in one of the above comment SOF: v1.6 Device: DVT1-C3 Check the video: https://www.youtube.com/watch?v=PC2SIuumcqU, playback on speaker with a 997Hz audio.

As you can see from the video, when I hit enter, bunch of messages printed in the right terminal immediately. you can check how long SOF is recovered from suspend, It doesn't takes that long. On my side， from Turning i915 HDAC power 1 to ipc tx succeeded: 0x40020000: GLB_CTX_RESTORE takes about 200ms

Please put below file to /etc/modprobe.d/, and rename it to sof-dyndbg.conf; open two terminals, one for aplay on speaker, and the other for dmesg monitoring like I do in the video. From the dmesg, we can know if it is SOF stuck somewhere or the aplay process stuck somewhere. sof-dyndbg.conf.txt

Edit: @lihow731 I am using ubuntu 20.04.1, are you using 20.10 or?

[lihow731]

@aiChaoSONG Please check this video on google driver

kernel: Kernel: sof-dev-rebase-20201201 (in above comment) topology: sof-cml-rt711-rt1308-rt715.zip (in above singalsu's comment) I enabled the dyndbg that your sof-dyndbg.conf.

I use ubuntu 20.04 (LTS, but this version is a oem preload version. It is close ubuntu 20.04.1.).

[keyonjie]

The issue is actually not fixed by #3708 by @lihow731, reopen it.

[keyonjie]

@lihow731 it sounds better with your latest video, do you think we can close this?

[lihow731]

@keyonjie if this is a device specific issue, I am fine to close it. But, I observed this issue on other machines that is no a soundwire audio. I hope we can find the root cause.

[aiChaoSONG]

@lihow731 In the latest video you posted, I think we are aligned on the time delay, about 200ms, Do you think it is still very long for you?

[lgirdwood]

codec HW will power on slowly to reduce pops and clicks. So I would expect to see some ramping an most devices. IIRC we do this in FW for some devices too. @keyonjie @aiChaoSONG

[lihow731]

@lgirdwood Got it. It's an expected behavior. I agree to close this issue. Thank you.