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

[Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>]

>>> I see, the issue is that I cannot find any way to give the metadata to
>>> the decoder module, it is a black box to us.
>>
>> The metadata is typically handled *outside* of the decoder library by a
>> memcpy-based wrapper or modulo pointers.
>>
>> For example due to the filterbank, the decoder will generate N zero
>> samples in the first frame. If you know the value of N thanks to the
>> METADATA ioctl, you can discard the first N samples in the wrapper.
>>
>> Likewise at the end of the track the wrapper can skip the last M samples
>> which were padded to make the initial soundtrack a multiple of the frame
>> size (e.g. 1152 for MP3). the value M is the encoder padding.
> 
> I got this part, but I have no idea how the wrapper could know this.
> It can be only _after_ the decoder to do the fade out/in/mixing, but so
> far I have not seen any way to actually pin-point the exact time.
> And not just exact time, but T minus something to T plus something.

It's not time you need to track but bytes, and the accuracy of the
next-track position is exactly a byte. If you're off by even one byte,
you probably lost a minimum of one frame until the decoder re-syncs for
an elementary stream, and the whole scheme is down the drain if there's
a header.

Also the decoder has to in a wrapper anyways, even without gapless
playback: the fragments used by the compressed framework may contain
more or less than a frame, so the decoder needs to deal with all cases
of 'no enough data available' and 'more than one frame provided'.
Likewise some decoder may not be able to generate data on initial calls,
and need to be called without new input to full internal PCM buffers.

then the logic should be:

(a) On a new track, for the first decoder you skip the first N samples.

(b) The end of track happens when all the bytes have been provided to
the decoder, and the decoder cannot generate more data. At that point
you would discard the last M padding samples.

(c) if there was a NEXT_TRACK, eset the byte counting for the track and
go back to (a)

That's the high level logic. Now for the positioning, I may be wrong but
I think there is a requirement that the NEXT_TRACK is only signaled when
all the bytes for the current track were provided to the driver. So on
the NEXT_TRACK you would need to record the number of bytes provided so
far by userspace, and forward that information to firmware. Then the
next write would be with the content for the next track. It could also
be the PARTIAL_DRAIN that does this, since at that point no new data
should be provided by userspace. Either way, do no write data in the
ring buffer until the firmware knows the total number of bytes in the
current track. If the app doesn't respect that then the accounting will
go sideways.

The last time I saw DSP code for this was in 2013 or so, take this with
a grain of salt. Vinod, if you have a better memory please do chime in...

>>> Also I'm not sure how the fw could get any idea where one
>>> flac/vorbis/aac/mp3 ends and where it starts, the black box does not
>>> seam to be able to detect this or if it does, it will not emit this
>>> information to outside.
>> I must admit I don't fully remember the details on the start/end
>> position. IIRC this isn't strictly required for elementary streams such
>> as MP3 or AAC ADTS, you could cat the streams together and that'd be
>> just fine. you would have a slightly different transition by blending
>> the two streams in a common filterbank history buffer but that'd be
>> nearly impossible to detect...
> 
> and there is still the monitoring of the progress of let's say 6th track
> in the stream.
> 
> I was planning to revisit this sooner than later when I have a moment of
> 'free' time, but for this initial series, it is not promised and should
> not work at all.
> 
>> But for streams with a header such as WMA not sure how this might work,
>> I think you do need to know the buffer position, reset the decoder and
>> restart from that position.
> 
> Luckily no one has such files anymore ;)

Hehe, the Zune music service only stopped in 2017...