Re: [PATCH 04/23] ASoC: soc-compress: Implement trigger FE-BE sequencing as with normal PCMs

[Vinod Koul <vkoul@kernel.org>]

On 08-09-26, 11:41, Péter Ujfalusi wrote:
> 
> 
> On 08/09/2026 09:58, Vinod Koul wrote:
> >> The only 'documentation' for the gapless (next_track + partial_drain)
> >> that I could find was the fcplay (and that could not have been worked
> >> (metadata and next_track was in wrong order).
> > 
> > Please see Documentation/sound/designs/compress-offload.rst, it has a
> > section on gapless with SM as well.
> 
> Thanks, for some reason I missed this, looks pretty well defined and
> written!

Thats okay, glad that you found it useful

> 
> > 
> >> But, reading the code it implies that gapless must support anything
> >> thrown at it in any order as for consecutive files:
> >> metadata
> >> next_track
> >> set_codec_params
> >> partial_drain
> > 
> > It was supposed to be in a specific sequence. See the sequence in the
> > documentation.
> 
> The documentation confirms that the fcplay was incorrect:
> https://github.com/alsa-project/tinycompress/commit/7d41dc4bcd39a1b2c449a6f87e827bdbd84d1213

OKay, feel free to send a patch, we should be consistent with above
documented behaviour

> 
> >> With IPC4 the NOP strategy works (just streaming the files without
> >> stopping, but they mus be of same format and property), but then you
> >> loose the position, so not so great.

I wanted to ask earlier, whats IPC4?

> >>
> >>> Note that the NEXT_TRACK only works if the two consecutive tracks have
> >>> the same format, if the platform wants 'perceived' gapless playback with
> >>> a x-fade then two devices are required.
> > 
> > Yes, same format always. Codec can skip the trailing and leading zeros
> > in that case. two different formats would need code switch/code setting
> > params, so it wont work and we would need two devices to x-fade as you
> > rightly pointed out
> 
> gapless looks to be straight forward fort he first look. What made me
> delay the implementation was the fact that I could not find any way in
> firmware to support the metadata as one - OK, I can just ignore it.
> second: in kernel and in firmware I could not figure out _where_
> actually is the end of the current file in the buffer. In kernel we have
> circular buffer for the DMA and userspace just fills it and since for
> the kernel it is just data, it looks continuous.
> The firmware can detect the end of a compressed file, so I can sort of
> support the drain and partial_drain but to get this whole thing working
> was just not something I could do blindly.

The kernel should view this as a continuous bit stream and wont know
EOF. Only firmware will know about it and with metadata, able to skip
those.

> Also: I have assorted ogg/mp3/flac in my music library and I tend to
> play them in random, which defeats the gapless.

You are a non typical users :-) To test this, we would same track in
album. A typical user would be running spotify with same format :-)

> The gapless support is not covered in this initial version, but can be
> added later.
> 

-- 
~Vinod