thesofproject
ASoC: SOF: ipc4-pcm: Delay reporting is only supported for playback d…
…irection
The firmware does not provide any information for capture streams via the shared pipeline registers.
To avoid reporting invalid delay value for capture streams to user space we need to disable it.
Fixes: af74dbd0dbcf ("ASoC: SOF: ipc4-pcm: allocate time info for pcm delay feature") Cc: [email protected]
@ujfalusi are you saying we are missing information about capture streams ? is this a FW bug ? @kv2019i
I think it is by design in firmware that no pipeline information is kept for capture streams: https://github.com/thesofproject/sof/blob/c1df459ca914c89d3cd51bac44a9e683d8eba395/src/audio/copier/copier.c#L327
Somehow the number of fw registers section depends on the number of playback channels: https://github.com/thesofproject/sof/blob/c1df459ca914c89d3cd51bac44a9e683d8eba395/src/audio/copier/copier_host.c#L108-L111
The pipeline regs are only initialized in case of playback, that's why pipeline_reg_offset remains 0 for capture streams:
https://github.com/thesofproject/sof/blob/c1df459ca914c89d3cd51bac44a9e683d8eba395/src/audio/copier/copier_host.c#L212
It looks to be by design.
I could handle this in kernel, but it is only going to work for HD-DMA on link side and even with that it is not going to work in case of a split topology path (one DAI to multiple PCMs). It is better and safer to not report the delay in capture at all.
I could handle this in kernel, but it is only going to work for HD-DMA on link side and even with that it is not going to work in case of a split topology path (one DAI to multiple PCMs). It is better and safer to not report the delay in capture at all.
We should really fix in FW and support this for capture. @ujfalusi can you create a FW ticket on what you expect and how kernel could detect if available.
I could handle this in kernel, but it is only going to work for HD-DMA on link side and even with that it is not going to work in case of a split topology path (one DAI to multiple PCMs). It is better and safer to not report the delay in capture at all.
We should really fix in FW and support this for capture. @ujfalusi can you create a FW ticket on what you expect and how kernel could detect if available.
I don't think it's worth changing the interface, the delay only makes sense for large buffers on playback. We have yet to see a case where a large buffer is needed on capture.
