public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthias Reichl <hias@horus.com>
To: Markus Elfring <Markus.Elfring@web.de>
Cc: alsa-devel@alsa-project.org, kernel-janitors@vger.kernel.org,
	Dom Cobley <popcornmix@gmail.com>,
	Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ALSA: pcm: fix ELD constraints for (E)AC3, DTS(-HD) and MLP formats
Date: Sun, 25 Jun 2023 16:13:08 +0200	[thread overview]
Message-ID: <ZJhLdE7oXAvIi1Yi@camel3.lan> (raw)
In-Reply-To: <08b8fa18-9520-2959-a6c9-6ea6132d9b46@web.de>

On Sun, Jun 25, 2023 at 02:10:21PM +0200, Markus Elfring wrote:
> …
> > This patch fixes the constraints for the common AC3 and DTS formats,
> …
> 
> Please add an imperative change suggestion.

I assumed the motivation was pretty clear from the paragraph above which you
snipped off:

> The SADs of compressed formats contain the channel and sample rate
> info of the audio data inside the compressed stream, but when
> building constraints we must use the rates and channels used to
> transport the compressed streams.
>
> eg 48kHz 6ch EAC3 needs to be transmitted as a 2ch 192kHz stream.

The previous implementation added constraints that could be both too broad
and incomplete at the same time, leading to the audio device accepting
channel/rate combinations that are not supported by the sink while rejecting
combinations that are required to transmit the compressed bitstream.

Typical impact on users is eg "Dolby TrueHD passthrough does not work".

Consider this EDID audio block of a 2020 Sony TV which rejected Dolby TrueHD
passthrough:

    Linear PCM:
      Max channels: 6
      Supported sample rates (kHz): 192 176.4 96 88.2 48 44.1 32
      Supported sample sizes (bits): 24 20 16
    AC-3:
      Max channels: 6
      Supported sample rates (kHz): 48 44.1 32
      Maximum bit rate: 640 kb/s
    DTS:
      Max channels: 6
      Supported sample rates (kHz): 48 44.1 32
      Maximum bit rate: 1504 kb/s
    Enhanced AC-3 (DD+):
      Max channels: 8
      Supported sample rates (kHz): 48 44.1
      Supports Joint Object Coding
    MAT (MLP):
      Max channels: 8
      Supported sample rates (kHz): 48
      Supports Dolby TrueHD, object audio PCM and channel-based PCM
      Hash calculation not required for object audio PCM or channel-based PCM

The old implementation didn't add the 192kHz / 8ch combination that's required
to transport the MLP TrueHD bitstream, so opening the device in 8ch 192kHz mode
failed.

> How do you think about to add the tag “Fixes”?

I've thought about that but decided against it as adding exact constraints
has the chance of breaking existing applications that accidentally relied on
the (incorrect) previous behaviour of adding rather broad constraints.

Consider the following EDID of a 2009 Sony TV:

    Linear PCM:
      Max channels: 2
      Supported sample rates (kHz): 48 44.1 32
      Supported sample sizes (bits): 24 20 16
    AC-3:
      Max channels: 6
      Supported sample rates (kHz): 48 44.1 32
      Maximum bit rate: 640 kb/s
    Enhanced AC-3 (DD+):
      Max channels: 6
      Supported sample rates (kHz): 48 44.1 32

The old implementation would have constraints that allowed up to 6ch output at
32/44.1/48kHz while the correct setup would be to only allow max 2ch output
(both AC3 and EAC3 bitstreams are transmitted in 2ch mode).

So you could successfully output eg 6ch audio (which the sink likely wouldn't accept
and/or only output the first 2 channels) before but now this will get rejected.

so long,

Hias

      parent reply	other threads:[~2023-06-25 14:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-24 16:52 [PATCH] ALSA: pcm: fix ELD constraints for (E)AC3, DTS(-HD) and MLP formats Matthias Reichl
2023-06-25  8:34 ` Takashi Iwai
     [not found] ` <08b8fa18-9520-2959-a6c9-6ea6132d9b46@web.de>
2023-06-25 14:13   ` Matthias Reichl [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=ZJhLdE7oXAvIi1Yi@camel3.lan \
    --to=hias@horus.com \
    --cc=Markus.Elfring@web.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=popcornmix@gmail.com \
    --cc=tiwai@suse.com \
    /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