On 7/3/20 4:47 AM, Srinivas Kandagatla wrote:
Thanks Pierre for the comments,
+Adding Patric Lai into loop,
On 02/07/2020 16:00, Pierre-Louis Bossart wrote:
On 7/2/20 6:11 AM, Srinivas Kandagatla wrote:
For gapless playback its possible that each track can have different
codec profile with same decoder, for example we have WMA album,
we may have different tracks as WMA v9, WMA v10 and so on
Existing code does not allow to change this profile while doing gapless
playback.
This patch adds new SNDRV_COMPRESS_SET_CODEC_PARAMS IOCTL to allow
userspace to set this new parameters required for new codec profile.
That does not seem fully correct to me. WMA profiles are actually
different encoding schemes - specifically the WMA 10 LBR.
The premise for gapless playback was that the same codec and profile
be used between tracks, so that the same internal delay was used. If
you look at the output data, it's made of zeroes for N samples, and
then you see decoded data. When you change tracks, the first N samples
actually come from the previous track.
If you change coding schemes between tracks, you cannot call this
gapless playback. You will both remove the last N samples of the
previous track and insert M zeroes (for the new decoder).
If you wanted to support such a mode, you would need to provide an
indication of the delay difference, e.g. by looking at the ID3 tags
and let firmware realign. Unfortunately, you don't send this
information with the new IOCTL? You would also need firmware tricks
for the first decoder to flush out its output and the new decoder to
realign.
I also don't see how one might end-up with different profiles for an
album in the first place. The gapless use came mostly from ripping
live music recorded on audio CDs in different tracks, and it would
have taken a twisted mind to select different encodings between tracks.
If the 'album' is really a playlist, then the gapless playback as
supported by the ASoC compressed layer is nearly useless. What you
would really want is cross-fade but that's a different use case and
implementation that would be needed.
Patrick seems to have discussed this topic in detail at one of the audio
conf!
He might want to add more to this discussion.
One more counter-argument I thought of after sending my response. If the
samples for the previous track and the next track are not generated by
the *same* filterbank, then you would lose the implicit averaging
between tracks performed by the filterbank (usually an inverse MDCT),
which will likely result in sample discontinuities and pop noise on
transitions. If we have different filterbanks we should really look into
explicit cross-fading which is a much larger change than what this patch
suggests.
