Re: [PATCH v3 1/3] ALSA: compress: add raw opus codec define and opus decoder structs

["Alexey Klimov" <alexey.klimov@linaro.org>]

On Thu Sep 18, 2025 at 6:08 AM BST, Vinod Koul wrote:
> On 17-09-25, 08:32, Alexey Klimov wrote:
>> Adds a raw opus codec define and raw opus decoder structs.
>> This is for raw OPUS packets not packed in any type of container
>> (for instance OGG container). The decoder struct fields are
>> taken from corresponding RFC document: RFC 7845 Section 5.
>> 
>> Cc: Srinivas Kandagatla <srini@kernel.org>
>> Cc: Vinod Koul <vkoul@kernel.org>
>> Co-developed-by: Annemarie Porter <annemari@quicinc.com>
>> Signed-off-by: Annemarie Porter <annemari@quicinc.com>
>> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
>> ---
>>  include/uapi/sound/compress_params.h | 43 +++++++++++++++++++++++++++++++++++-
>>  1 file changed, 42 insertions(+), 1 deletion(-)
>> 
>> diff --git a/include/uapi/sound/compress_params.h b/include/uapi/sound/compress_params.h
>> index bc7648a30746f4632ecf6695868e79550a431dfa..faf4fa911f7fc2830c3ae42b93650fe40d8a776b 100644
>> --- a/include/uapi/sound/compress_params.h
>> +++ b/include/uapi/sound/compress_params.h
>> @@ -43,7 +43,8 @@
>>  #define SND_AUDIOCODEC_BESPOKE               ((__u32) 0x0000000E)
>>  #define SND_AUDIOCODEC_ALAC                  ((__u32) 0x0000000F)
>>  #define SND_AUDIOCODEC_APE                   ((__u32) 0x00000010)
>> -#define SND_AUDIOCODEC_MAX                   SND_AUDIOCODEC_APE
>> +#define SND_AUDIOCODEC_OPUS_RAW              ((__u32) 0x00000011)
>> +#define SND_AUDIOCODEC_MAX                   SND_AUDIOCODEC_OPUS_RAW
>>  
>>  /*
>>   * Profile and modes are listed with bit masks. This allows for a
>> @@ -324,6 +325,45 @@ struct snd_dec_ape {
>>  	__u32 seek_table_present;
>>  } __attribute__((packed, aligned(4)));
>>  
>> +/**
>> + * struct snd_dec_opus - Opus decoder parameters (raw opus packets)
>> + * @version: Usually should be '1' but can be split into major (4 upper bits)
>> + * and minor (4 lower bits) sub-fields.
>
> Please clarify, if that should be 1.0 so a value of 0x10

Sorry for the delay.
So the spec says that the value must be '1' for 8-bit field for that
version of specification which it seems it should be 0x1.
The spliting into two 4-bit fields is for backward compatibility and
in such case any version in minor fields will be accepted (15 or less).
Anything starting with version 16 or 0x10 is treated as incompatible
version for this version of spec.

Well, at least that's how I understand the spec.
Value 0x10 in this case seems to signal incompatibility unless I am
missing something?

Thanks,
Alexey