audio: codec_adapter: DTS codec problem when running with sof-mt8195-mt6359-rt1019-rt5682 topology

[markbartonxperi]

As a result of some internal testing on a machine running the sof-mt8195-mt6359-rt1019-rt5682 topology (but modified to use our DTS Codec pipeline on the speaker path in place of the passthrough pipeline) I received a bug report that audio output was not correct. In the recording I was sent I hear a small segment of buffer repeating ~10 times, then skipping ahead to another segment of buffer, which then repeated.

Looking at the sof log for the machine under test, a buffer under-run is being reported:

eg:

[   205547880.373928] (       54166.871094) c0 dai          1.6            src/audio/dai.c:954  WARN dai_copy(): Copy_bytes 192 + avail bytes 0 < period bytes 1920, possible glitch
[   205561422.248390] (       13541.874023) c0 dai          1.6            src/audio/dai.c:963  WARN dai_copy(): nothing to copy

... repeat many times...

Unfortunately I don't have access to the machine under test - my development system is an UP! Xtreme board, on which everything works. However, I compared the sof-hda-generic topology I use with the sof-mt8195-mt6359-rt1019-rt5682 topology and noticed the pipeline period in the sof-mt8195-mt6359-rt1019-rt5682 case was 10000, as opposed to 1000. After changing the PIPELINE_PCM_ADD and DAI_ADD declarations in sof-mt8195-mt6359-rt1019-rt5682.m4 and redeploying the topology to the machine under test, everything starting working.

Conversely, when I change the PIPELINE_PCM_ADD and DAI_ADD declarations in my version sof-hda-generic.m4 to use a period of 10000, I am able to replicate the problem heard on the machine under test in my environment.

Repeating the test with my codec_adapter-based DTS codec removed from the pipeline and only EQ in place, everything works on the machine under test with a period of either 1000 or 10000, which made me suspicious of my implementation, of course. I felt like I should be detecting a change in period (from 192 to 1920) somewhere in the life-cycle of my codec, which I should interpret as a signal to reallocate my input and output buffers. I've added logging in a fair-few locations now, and the period is always reported to my code as 192 bytes.

Is there something other than the period that I'm meant to check in order to understand that I should allocate larger buffers?

Thanks in advance
Mark

[lgirdwood]

@markbartonxperi this looks like your workload has overshot the timeslice. The low latency (LL) scheduler has a default 1ms time slice that the DMA also uses to copy data to/from audio end points. A few things to try to confirm

1. Trim the workload down a bit with a simple config (one you know is deterministic and simple) and rerun. This should hopefully reduce bug occurrence ?
2. Increasing the tick (but this also means you need to build bigger buffers for all components in the pipeline) as they will be filled/emptied less often.
3. Try running your workload in EDF context on core 1. We do this for other workloads that need more time to process or have variable runtime loads. Cost is more complexity or power.

[lgirdwood]

@markbartonxperi btw - good for a quick call next week if you want a chat.

[markbartonxperi]

@lgirdwood Thanks for the reply.

To test your theory I took your advice in (1) - I took my DTS codec, as-is, but substituted the call to my processing with the memcpy operation from the passthrough codec. So the processor load in process is now almost zero. Running this on my dev board still results in the same nasty sounding audio. I was surprised about this!

The thing I'm a bit confused by is that whatever I set the period to in the topology, the number of period bytes reported to me in my prepare function is always 192. It almost feels like there's a loop missing in the codec_adapter itself that should be calling my code x10 to fill the entire buffer its being asked to fill....

Are you able to double check that what I'm configuring in my sof-hda-generic topology is correct to replicate the current mt8195 topology:

# Low Latency playback pipeline 1 on PCM 0 using max 2 channels of s24le.
# 1000us deadline with priority 0 on core 0
PIPELINE_PCM_ADD(PIPE_HEADSET_PLAYBACK,
	1, 0, 2, s24le,
	10000, 0, 0,
	48000, 48000, 48000)

-----

# playback DAI is HDA Analog using 2 periods
# Dai buffers use s32le format, 1000us deadline with priority 0 on core 0
DAI_ADD(sof/pipe-dai-playback.m4,
        1, HDA, 0, Analog Playback and Capture,
        PIPELINE_SOURCE_1, 2, s32le,
        10000, 0, 0, SCHEDULE_TIME_DOMAIN_TIMER)

If you're available for a chat next week, that would be great. Aside from this particular problem, would be good to meet and put a face to the name, as it were :)

Thanks!

[lgirdwood]

@markbartonxperi so the changes above should permit a passthrough copy() to be called once every 10ms (you should see this in the logs), but I'm not sure why the code adapter would still give you 192 bytes (48 frames or 1ms worth of data). Can you make sure the buffers are large enough to take at least 20ms of data (I'm thinking you are getting 192 as the buffers are overrunning ?)

[markbartonxperi]

@lgirdwood I'm on annual leave at the moment, but I took a quick look at this earlier.

If I allocate input and output buffers that are 20ms long, and use codec_processing_data.avail to drive the amount of data available to process, then everything works with the pipeline period set to 10000.

My next question is: how do I know what buffer size to allocate in my prepare function? Ideally I want to allocate based on the hosting pipeline's period so that my buffers are as small as they can be, and parameter updates to my processing have the lowest latency. I haven't really dug into the available hierarchy of structures, but it wasn't immediately obvious where to find that particular value.

Maybe also worth noting that I modelled my implementation on codec_adapter/codec/passthrough.c which allocates its buffers based on the size reported in period_bytes. I'm pretty sure that this would mean the passthrough codec will have the same problem as my code when faced with a pipeline of period 10000.

Thanks for your help!!

[lgirdwood]

@markbartonxperi any update ?

[markbartonxperi]

@lgirdwood Apologies for the delayed reply.
As we were able to change the pipeline period for the topology of interest (mt8195) to 1000 we've been able to work around this issue in the short term.
However, it would be great to work out what changes I need to make to allow our codec to work with an optimal buffer size for any pipeline period.
I think you mentioned that I should try following up with @singalsu about this to see if they had any thoughts.
@singalsu: hopefully there's already enough information here to follow where I'm currently with this issue and what I've tried so far, but if there's any more information you need, let me know.

[singalsu]

@markbartonxperi Does dev->frames work for you? It's set by framework to nominal frames count per copy() schedule. I'm using it in many components to allocate resources. I'm assuming e.g. max 1.1 times of that to be max. samples to process. Maybe that's today a bit excessive so could be closer to 1.0. Due to timer based scheduling there's quite often +/- 1 frames jitter in frames avail/free in buffers.

[markbartonxperi]

@singalsu Thanks for the input.
I took a look at this today.... I'll try and summarise some of the above and describe what I've looked into today, as I feel like I'm missing something very obvious here :)

My test system is an Up! Xtreme, so I'm working with the sof-hda-generic.m4 topology. I insert my codec on pipeline 1, which corresponds to the headphone output on that board.

In the first test I log the value of dev->frames using the default pipeline configuration in the m4 file:

# Low Latency playback pipeline 1 on PCM 0 using max 2 channels of s24le.
# 1000us deadline with priority 0 on core 0
PIPELINE_PCM_ADD(PIPE_HEADSET_PLAYBACK,
	1, 0, 2, s24le,
	1000, 0, 0,
	48000, 48000, 48000)

My logging reports the value of dev->frames to be 48, which is expected.

In the second test I change the pipeline configuration to reproduce the conditions for the mt8195 system that I'm ultimately targeting (I don't have physical access to this system, unfortunately) my .m4 file looks like this:

# Low Latency playback pipeline 1 on PCM 0 using max 2 channels of s24le.
# 1000us deadline with priority 0 on core 0
PIPELINE_PCM_ADD(PIPE_HEADSET_PLAYBACK,
	1, 0, 2, s24le,
	10000, 0, 0,
	48000, 48000, 48000)

In this case, my logging still reports the value of dev->frames to be 48, which I'm not expecting. I would expect this to be 480 so that my code knows it needs to allocate a larger buffer to 'cope' with the larger pipeline period and avoid buffer underruns.

[singalsu]

@markbartonxperi Ouch, that looks like a bug in the framework or topology macros. Need to find out where.

[lgirdwood]

Thanks @singalsu - lets take this fix for rc2.

[markbartonxperi]

@singalsu @lgirdwood Let me know if you want me to test anything, or debug any code paths with logging on my system.
Thanks