snd_pcm_delay() reporting unexpected values

[kv2019i]

While testing a new extension to alsa-conformance-test to report PCM delay values, I noticed MTL on hda-generic tplg, is reporting odd seeming values (negative delays).

Environment

kernel: 66ee247 (sof-dev)
SOF: 6c188298b958 (SOF main)
platform: MTL
topoplogy: sof-hda-generic-4ch.tplg

Expected outcome

Definition of the PCM delay in alsa-lib is as follows:

 * For playback the delay is defined as the time that a frame that is written                                                                                                                
 * to the PCM stream shortly after this call will take to be actually                                                                                                                        
 * audible. It is as such the overall latency from the write call to the final                                                                                                             

Actual outcome

Negative values reported even if no underrun/overrun condition is seen on the stream. It seems the link position is ahead of the host position, which can't be correct for playback.

Ways to test

• kernel RD patch kv2019i@8febce4
• or use alsa_conformance_test in debug mode and take code from branch https://github.com/kv2019i/cros-audiotest/tree/topic/pcm-delay-debug (UPDATE 22nd Jan: added one patch to the branch to print out calculated delay-corrected playback position to debug output)

Example error

aplay -Dhw:0,0 -traw -fdat /dev/zero

Output from the kernel RD patch:

[ 2106.387543] sof-audio-pci-intel-mtl 0000:00:1f.3: pcm_delay: d=4611686018427387542, tmp=362, pos=1052, hw_ptr=0, start=690,llp=0
[ 2106.468925] sof-audio-pci-intel-mtl 0000:00:1f.3: pcm_delay: d=4611686018427383829, tmp=4267, pos=4958, hw_ptr=192, start=690,llp=0
[ 2106.469404] sof-audio-pci-intel-mtl 0000:00:1f.3: pcm_delay: d=4611686018427387742, tmp=4290, pos=4981, hw_ptr=4128, start=690,llp=0
[ 2106.553960] sof-audio-pci-intel-mtl 0000:00:1f.3: pcm_delay: d=4611686018427383683, tmp=8349, pos=9039, hw_ptr=4128, start=690,llp=0
[ 2106.554421] sof-audio-pci-intel-mtl 0000:00:1f.3: pcm_delay: d=4611686018427387741, tmp=8371, pos=9062, hw_ptr=8208, start=690,llp=0
[ 2106.638929] sof-audio-pci-intel-mtl 0000:00:1f.3: pcm_delay: d=4611686018427383684, tmp=12428, pos=13118, hw_ptr=8208, start=690,llp=0

Output from alsa_conformance_test ("alsa_conformance_test -Phw:0,0 --debug")

TIME_DIFF(s)    HW_LEVEL     PLAYED       DIFF               RATE      DELAY
0.000037840          288        192        192     5073995.771670 4611686018427388022
0.000080551          240        240         48      595895.767899 4611686018427388018
0.000994502          432        288         48       48265.362966 4611686018427388210
0.001015976          384        336         48       47245.210517 4611686018427388162
0.000983345          336        384         48       48812.980185 4611686018427388114

[kv2019i]

@RanderWang Can you check? Anythinig I'm missing in the test procedure?

[RanderWang]

I am working on it. The reason is related to both fw and kerne driver. We change driver logic : send ipc start first or start host dma first

[RanderWang]

[83694.972961] snd_sof 0000:00:1f.3: ipc tx 0x13000004|0x1: GLB_SET_PIPELINE_STATE [data size: 12]
[83694.993852] snd_sof 0000:00:1f.3: ipc tx reply: 0x33000000|0x1: GLB_SET_PIPELINE_STATE
[83694.993886] snd_sof 0000:00:1f.3: ipc tx done : 0x13000004|0x1: GLB_SET_PIPELINE_STATE [data size: 12]
[83694.993899] Message payload: 00000000: 00000002 00000001 00000000
[83694.993907] sof-audio-pci-intel-mtl 0000:00:1f.3: +++++++ stream start +++++++

[83694.984310] copier: copier_comp_trigger: comp:0 0x4 copier_comp_trigger() cmd 7
[83694.984341] copier: copier_comp_trigger: comp:0 0x4 copier_comp_trigger() cmd 1
[83694.984376] copier: copier_comp_trigger: comp:0 0x4 ------- dai pos 4216, dai link 522

FW start to calculate position for HDA host dma stream at 83694.984376 for stream start msg, but HDA stream was started at 83694.993907 in host kernel, almost 10ms later, so at least 480 samples error

[plbossart]

the position in the firmware should be updated when data is received, not when the pipeline is started?

[RanderWang]

the position in the firmware should be updated when data is received, not when the pipeline is started?

this is for stream_start_offset which is to remove the dai link count before host stream is started like mixer case or dai pipeline is started before host pipeline. Yes, your idea is in my shop list. Current design follows REF FW

Sleep 10 MS after the stream is started in FW should be the root reason

/* wait for IPCs to complete on other cores and be nice to any LL work */
static int ipc_wait_for_compound_msg(void)
{
	int try_count = 30; /* timeout out is 30 x 10ms so 300ms for IPC */

	while (atomic_read(&msg_data.delayed_reply)) {
		k_sleep(Z_TIMEOUT_MS(10));

		if (!try_count--) {
			atomic_set(&msg_data.delayed_reply, 0);
			ipc_cmd_err(&ipc_tr, "ipc4: failed to wait schedule thread");
			return IPC4_FAILURE;
		}
	}

	return IPC4_SUCCESS;
}

[RanderWang]

Let's discuss this commit: thesofproject/sof@909a327

This commit results to a batch of host warning since host kernel is blocked to start HDA DMA

[ 4580.800270] <inf> copier: copier_comp_trigger: comp:0 0x4 copier_comp_trigger() cmd 7
[ 4580.800293] <inf> copier: copier_comp_trigger: comp:0 0x4 copier_comp_trigger() cmd 1
[ 4580.800328] <err> copier: copier_comp_trigger: comp:0 0x4 ------- dai pos 4288, dai link 527
[ 4580.800350] <inf> host_comp: host_get_copy_bytes_normal: comp:0 0x4 no bytes to copy, available samples: 0, free_samples: 192
[ 4580.801273] <inf> host_comp: host_get_copy_bytes_normal: comp:0 0x4 no bytes to copy, available samples: 0, free_samples: 192
[ 4580.802271] <inf> host_comp: host_get_copy_bytes_normal: comp:0 0x4 no bytes to copy, available samples: 0, free_samples: 192
[ 4580.803271] <inf> host_comp: host_get_copy_bytes_normal: comp:0 0x4 no bytes to copy, available samples: 0, free_samples: 192
[ 4580.804271] <inf> host_comp: host_get_copy_bytes_normal: comp:0 0x4 no bytes to copy, available samples: 0, free_samples: 192
[ 4580.805271] <inf> host_comp: host_get_copy_bytes_normal: comp:0 0x4 no bytes to copy, available samples: 0, free_samples: 192
[ 4580.806273] <inf> host_comp: host_get_copy_bytes_normal: comp:0 0x4 no bytes to copy, available samples: 0, free_samples: 192
[ 4580.807271] <inf> host_comp: host_get_copy_bytes_normal: comp:0 0x4 no bytes to copy, available samples: 0, free_samples: 192
[ 4580.808271] <inf> host_comp: host_get_copy_bytes_normal: comp:0 0x4 no bytes to copy, available samples: 0, free_samples: 192
[ 4580.809253] <inf> host_comp: host_get_copy_bytes_normal: comp:0 0x4 no bytes to copy, available samples: 0, free_samples: 192
[ 4580.810258] <inf> host_comp: host_get_copy_bytes_normal: comp:0 0x4 no bytes to copy, available samples: 0, free_samples: 192
[ 4580.811248] <inf> host_comp: host_get_copy_bytes_normal: comp:0 0x4 no bytes to copy, available samples: 0, free_samples: 192

[ujfalusi]

@kv2019i, @RanderWang, can you try this patch:
0001-ASoC-SOF-ipc4-pcm-Correct-delay-reporting.patch.txt

[RanderWang]

@kv2019i, @RanderWang, can you try this patch: 0001-ASoC-SOF-ipc4-pcm-Correct-delay-reporting.patch.txt

I added comments in your commit. The issue is a little tricky, we need to refine both kernel and FW.

[RanderWang]

is https://github.com/thesofproject/linux/blob/topic/sof-dev/sound/soc/sof/intel/hda-stream.c#L1078 correct ?
In my opinion it should be

	if (pos >= hstream->bufsize)
		pos = 0;   // pos -= hstream->bufsize; ?		

[RanderWang]

is https://github.com/thesofproject/linux/blob/topic/sof-dev/sound/soc/sof/intel/hda-stream.c#L1078 correct ? In my opinion it should be

	if (pos >= hstream->bufsize)
		pos = 0;   // pos -= hstream->bufsize; ?		

I add some log and find that pos <= hstream->bufsize, never > hstream->bufsize, so no problem