From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Carlos Rafael Giani <crg7475@mailbox.org>,
Vinod Koul <vkoul@kernel.org>, Jaroslav Kysela <perex@perex.cz>,
Takashi Iwai <tiwai@suse.com>
Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ALSA: compress: Add AC3, EAC3, TrueHD, DTS, MPEG-H 3D Audio Stream (MHAS)
Date: Tue, 6 Dec 2022 09:34:09 -0600 [thread overview]
Message-ID: <186a5111-617d-c8f0-ba7e-1f39663c65dd@linux.intel.com> (raw)
In-Reply-To: <cdee3f7d-3f98-02dc-9fc6-18ffc489c6f8@mailbox.org>
On 12/6/22 09:16, Carlos Rafael Giani wrote:
> IEC61937 is quite commonly used, yes. However, I have been working with
> a commercial system that is getting support for these formats
> implemented via compress-offload. Since these formats aren't exactly
> uncommon, I figured that adding these could be useful, especially since
> only the #defines need to be added, nothing else.
please don't top-post on mailing lists.
Nothing else? That sounds to good to be true. Specifically for
spatialization, there's got to be some sort of interface to control
where the objects are located, either in reference to the listener
position or the listening room setup.
The compressed API was developed back in the early 2010s for elementary
streams, it's not been extended since and IMHO it's far too limited to
support Atmos and newer systems optimally.
> On 06.12.22 16:07, Pierre-Louis Bossart wrote:
>>
>> On 12/6/22 08:53, Carlos Rafael Giani wrote:
>>> These audio codecs are used in sound bars and digital TVs, and benefit
>>> from off-loading to a DSP. In particular, Dolby Atmos and MPEG-H 3D
>>> audio
>>> spatialization is done in dedicated DSPs. Thus, adding these codecs to
>>> the Compress-Offload API makes sense.
>> The question is "how is the stream transported". In most implementations
>> for these formats, the DSP is on the receiver side and the transport
>> happens with an IEC61937 format - which does not require the use of the
>> compressed API.
>>
>>> Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
>>> ---
>>> include/uapi/sound/compress_params.h | 8 +++++++-
>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/include/uapi/sound/compress_params.h
>>> b/include/uapi/sound/compress_params.h
>>> index ddc77322d571..7a58e2026be3 100644
>>> --- a/include/uapi/sound/compress_params.h
>>> +++ b/include/uapi/sound/compress_params.h
>>> @@ -43,7 +43,13 @@
>>> #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_AC3 ((__u32) 0x00000011)
>>> +#define SND_AUDIOCODEC_EAC3 ((__u32) 0x00000012)
>>> +#define SND_AUDIOCODEC_TRUEHD ((__u32) 0x00000013)
>>> +#define SND_AUDIOCODEC_DTS ((__u32) 0x00000014)
>> IIRC there are multiple flavors of DTS, off the top of my head DTS-ES,
>> 96, HD, Master Audio. "DTS" only doesn't even begin to describe the
>> possible variants.
And IIRC2 there is some level of backwards compatibility between
flavors, but the decoder may or may not be able to generate the number
of channels and formats supported in the initial stream. That's a
problem if you need to configure audio codecs or interfaces and the DSP
doesn't tell you what it decoded or upmixed.
>>> +/* MPEG-H 3D Audio Stream (MHAS) as defined in ISO/IEC 23008-3 */
>>> +#define SND_AUDIOCODEC_MHAS ((__u32) 0x00000015)
>> Doesn't this need the definition of profiles and various types of
>> formats - classic problem with designed-by-committee MPEG codecs.
>>
>>> +#define SND_AUDIOCODEC_MAX SND_AUDIOCODEC_MHAS
>>
>>> /*
>>> * Profile and modes are listed with bit masks. This allows for a
prev parent reply other threads:[~2022-12-06 15:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-06 14:53 Carlos Rafael Giani
2022-12-06 15:07 ` Pierre-Louis Bossart
2022-12-06 15:16 ` Carlos Rafael Giani
2022-12-06 15:34 ` Pierre-Louis Bossart [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=186a5111-617d-c8f0-ba7e-1f39663c65dd@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=crg7475@mailbox.org \
--cc=linux-kernel@vger.kernel.org \
--cc=perex@perex.cz \
--cc=tiwai@suse.com \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®