thesofproject / sof

Sound Open Firmware
Other
561 stars 318 forks source link

[FEATURE] ASRC component with i.MX #4206

Open iuliana-prodan opened 3 years ago

iuliana-prodan commented 3 years ago

Is your feature request related to a problem? Please describe. While trying to add the ASRC component to an i.MX pipeline I've realize that in our DAI (more specifically for i.MX, in SAI or ESAI) we don't have the timestamp_ops implemented. The problem is that our hardware, i.MX8QM and i.MX8QXP, doesn't have timestamp support.

Describe the solution you'd like Is there any possibly to use platform timer for ASRC? Will this impact the accuracy of the conversion?

Describe alternatives you've considered By looking on the SPP and HDA timestamp_ops implementation I realized that we need to determine each argument from

struct timestamp_data {
    uint64_t walclk; /* Wall clock */
    uint64_t sample; /* Sample count */
    uint32_t walclk_rate; /* Rate in Hz, e.g. 19200000 */ 
};

Will it be possible to compute:

Can this be a valid solution? @singalsu @tlauda

CC: @dbaluta @lgirdwood @paulstelian97 @ViorelSuman

lgirdwood commented 3 years ago

@iuliana-prodan platform timer could be used if its the same time domain that the DAI is using ?

dbaluta commented 3 years ago

@lgirdwood in our case DAI is using DMA domain. Our question is what exactly do we need to provide as an input to ASRC module in order to work if our DAI doesn't have support for timestamping and frame counting.

Actually, our DAI has support for this but only in a newer version not existent on i.MX8/i.MX8X.

singalsu commented 3 years ago

If there's no timestamp feature in HW there would be need for a timer count that is synchronized to audio clock generated by the SoC for e.g. codec that the rest of audio system is synchronized to. The DAI should count PCM frames consumed/produced by HW within timer values captured. There's likely need for stronger low-pass filtering for skew factor than with HW timestamps (minimal measure noise added). Also the update rate could be made longer than every 1ms copy() to have larger counts and less measure noise. Watch out for skew settle delay and possible xruns when enhancing filtering. Slow skew tracking can cause xruns. Also audio THD+N is a parameter to consider when adjusting skew filtering. Too fast skew tracking degrades THD+N. But all FW tracking it's possible and I was using such in tests before I got the HW timestamps to work.

iuliana-prodan commented 3 years ago

If there's no timestamp feature in HW there would be need for a timer count that is synchronized to audio clock generated by the SoC for e.g. codec that the rest of audio system is synchronized to.

Can the platform timer be used?

The DAI should count PCM frames consumed/produced by HW within timer values captured.

This represents the sample count from struct timestamp_data. Have I understood correctly?

If I can use the platform timer, the walclk_rate will be the platform frequency, right?

singalsu commented 3 years ago

@iuliana-prodan Yep, that's correct. If things are correct you will get in asrc_control_loop() a cd->skew value Q2.30 that is close to 1.0. When checking thinks I've output to trace the raw and filtered skew values and extracted them for Matlab plots with some scripts. It was an ugly hack so I've not shared code. Some well thought format to get trace data to Matlab and Octave or to other favorite maths tool would be nice to have.

iuliana-prodan commented 3 years ago

@singalsu Thank you! Will make a POC and tweak it later. With your help :)