ASoC: tas2783-sdw: no stereo channel split for two mono amps -> mono output (AMD ACP SoundWire, ASUS ProArt PX13)

ASoC: tas2783-sdw: no stereo channel split for two mono amps -> mono output (AMD ACP SoundWire, ASUS ProArt PX13)

[Antoine Monnet]

Hi,

On an ASUS ProArt PX13 (HN7306) with two mono TAS2783 SoundWire 
smart-amps on a
single AMD ACP SoundWire link, playback is effectively mono: only one amp
produces sound and it plays the *left* channel out of the *right* 
speaker; the
right channel and the other (left) speaker are silent. Both amps enumerate,
load firmware, and stream without any error.

Environment
-----------
Machine : ASUS ProArt PX13, HN7306 (Ryzen AI Max, "Strix Halo")
Distro : Debian 13 (trixie)
Kernel : 7.0.13+deb13-amd64 (Debian 7.0.13-1~bpo13+1); code identical in 
7.1.3
ACP : 0000:c4:00.5 [1022:15e2] rev 70, subsystem ASUSTeK [1043:1714],
driver snd_pci_ps
Amps : 2x TAS2783, SoundWire link 1, slaves 0x8 and 0xB
(sdw:0:1:0102:0000:01:8, sdw:0:1:0102:0000:01:b)

Note on the build: Debian ships sound/soc/codecs/tas2783-sdw.c but does 
not set
CONFIG_SND_SOC_TAS2783_SDW, so this is the unmodified in-tree driver 
built as an
out-of-tree module (DKMS). The relevant code is unchanged in current 
mainline
(verified against 7.1.3).

Analysis
--------
In tas_sdw_hw_params() the driver does:

snd_sdw_params_to_config(substream, params, &stream_config, &port_config);
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
port_config.num = 1;
else
port_config.num = 2;
sdw_stream_add_slave(sdw_peripheral, &stream_config, &port_config, 1,
sdw_stream);

snd_sdw_params_to_config() sets port_config.ch_mask to cover all stream 
channels
(0x3 for a 2-channel stream). This runs per-amp, so *both* mono amps are 
added
to the stream with ch_mask = 0x3 and neither is told which channel to 
reproduce.
There is no per-amp channel assignment anywhere in the driver (the only 
other
ch_mask use is the port-prep write of whatever mask was handed in). The 
result
on this board is mono out of a single amp.

Diagnosis on the hardware (per-amp mute + isolated-channel tests) confirmed:
only one amp (tas2783-2, the right speaker) outputs, playing the left 
channel;
the other amp (left speaker) is silent regardless of content; no 
"without fw"
or port/prepare errors on either slave.

Fix
---
Assign a single SoundWire channel per amp, e.g. right after
snd_sdw_params_to_config():

if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK &&
params_channels(params) == 2) {
switch (tas_dev->sdw_peripheral->id.unique_id) {
case 0x8: port_config.ch_mask = 0x1; break; /* left */
case 0xB: port_config.ch_mask = 0x2; break; /* right */
}
}

With this the two speakers are correctly driven:
speaker-test -Dpipewire -c2 -s1 -> left speaker
speaker-test -Dpipewire -c2 -s2 -> right speaker

The unique_id -> L/R mapping is board-specific, so a proper fix should 
derive
the per-amp channel assignment from firmware/ACPI (or a machine quirk table)
rather than hard-coded SoundWire addresses. Filing this so the driver 
grows a
real mechanism for multi-amp channel mapping.

Reproduce
---------
1. Boot; internal speakers play but only one speaker is audible.
2. speaker-test -Dpipewire -c2 -s1 -> wrong/only-one speaker
speaker-test -Dpipewire -c2 -s2 -> silent
3. With the per-amp ch_mask patch above, both speakers work.

Happy to test patches on this hardware.

Thanks,
Antoine

Re: ASoC: tas2783-sdw: no stereo channel split for two mono amps -> mono output (AMD ACP SoundWire, ASUS ProArt PX13)

[Andrey Golovko]

Hi Antoine,

Confirmed on a second machine: ASUS ProArt PX13 HN7306EAC (Ryzen AI MAX+
395), Ubuntu 26.04, 7.2-rc4 based kernel, same two TAS2783 at unique_id
0x8 / 0xB plus RT721 on SoundWire link 1.

Rather than judging by ear, I used the per-amp mixer controls, which
makes the result unambiguous. Both amps at full scale ('tas2783-1/-2 Amp
Volume' = 20, 'Speaker Volume' = 200), all four 'Left/Right Spk[2]
Switch' on:

  speaker-test -Dpipewire -c2 -s1 (left channel only)
    - audible
    - 'tas2783-2 Speaker Volume' = 0  -> complete silence
    - 'tas2783-1 Speaker Volume' = 0  -> no audible change

  speaker-test -Dpipewire -c2 -s2 (right channel only)
    - silent, with both amps unmuted at full scale

So exactly your picture: one amp (tas2783-2) renders audio and it renders
the *left* channel, the other amp contributes nothing, and the right
channel is never reproduced. Both amps do load their own per-address
blob here (1714-1-8.bin / 1714-1-B.bin, via the fallback naming path
after the 0x-prefixed names miss), so this is not a case of the wrong
configuration being downloaded.

On the "proper mechanism" question: a good part of the plumbing already
exists, and it does not need unique_id at all.

 - The machine layer already knows which amp is which. In
   sound/soc/sdw_utils/soc_sdw_ti_amp.c, asoc_sdw_ti_spk_rtd_init() maps
   the component name prefix to a speaker widget: tas2783-1 -> "Left
   Spk", tas2783-2 -> "Right Spk", tas2783-3/-4 -> "Left/Right Spk2".
   That is where the four 'Left/Right Spk[2] Switch' controls on this
   board come from.

 - asoc_sdw_hw_params() (sound/soc/sdw_utils/soc_sdw_utils.c) fills
   dai_link->ch_maps, but for playback it deliberately hands every codec
   the full mask ("Identical data will be sent to all codecs in
   playback"), leaving the per-amp channel selection to the amp itself.
   acp-sdw-legacy-mach, which drives this board, uses both.

So the driver could derive the channel from the same prefix index the
DAPM routing already uses, or from its entry in dai_link->ch_maps,
instead of hard-coding SoundWire addresses.

Which raises the question for TI: on TAS2783 is the channel selection
meant to come from the per-device .bin (in which case it is evidently
not taking effect on this board), or is the driver expected to program a
per-amp channel mask? Depending on the answer, either the firmware
description or tas_sdw_hw_params() needs fixing - and in the latter case
the amp's channel should come from the machine-level mapping rather than
from unique_id, which as you say is board-specific.

Happy to test patches on this hardware; I can also collect register
dumps from both amps if that helps.

Thanks,
Andrey

Re: ASoC: tas2783-sdw: no stereo channel split for two mono amps -> mono output (AMD ACP SoundWire, ASUS ProArt PX13)

[Antoine Monnet]

(Apologies — I sent that from the wrong identity. 
monnet.antoine@gmail.com and antoine@montane.tech are the same person)

Hi Andrey,

Thanks for the second-machine confirmation and for spelling out the
mechanism - I went with exactly your suggestion and keyed the channel off
the machine-assigned component prefix rather than unique_id.

I logged name_prefix against the resulting ch_mask and got tas2783-1 = 0x8
= left, tas2783-2 = 0xb = right; the split is correct by ear and by per-amp
mixer mute. Since your unit is the same HN7306EAC the prefix ordering is
identical, so this should give correct L/R for you too - a Tested-by from
the second machine would be welcome if you get a chance, but nothing needs
re-deriving.

On the ch_maps alternative you raised: since asoc_sdw_hw_params() hands
every codec the full mask for playback, dai_link->ch_maps doesn't carry a
per-amp selection there, so I took the prefix-index route. Happy to switch
to ch_maps if the machine layer is taught to fill per-amp maps first -
that's really the TI question below.

Patch below, against broonie/sound for-next.

  sound/soc/codecs/tas2783-sdw.c | 18 ++++++++++++++++++
  1 file changed, 18 insertions(+)

diff --git a/sound/soc/codecs/tas2783-sdw.c b/sound/soc/codecs/tas2783-sdw.c
--- a/sound/soc/codecs/tas2783-sdw.c
+++ b/sound/soc/codecs/tas2783-sdw.c
@@ -216,6 +216,24 @@ static s32 tas_sdw_hw_params(struct 
snd_pcm_substream *substream,
       /* SoundWire specific configuration */
       snd_sdw_params_to_config(substream, params,
                                &stream_config, &port_config);
+
+     /*
+      * The two mono amps each render one channel of the stereo stream:
+      * snd_sdw_params_to_config() hands every codec the full mask for
+      * playback, so without a per-amp channel selection only one amp would
+      * output. Derive the channel from the machine-assigned component
+      * prefix rather than the SoundWire address (which is board-specific):
+      * soc_sdw_ti_amp.c maps tas2783-1/-3 to the Left speaker and
+      * tas2783-2/-4 to the Right, so odd-indexed amps take the left
+      * channel and even-indexed the right.
+      */
+     if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK &&
+         params_channels(params) == 2 && component->name_prefix) {
+             const char *idx_str = strrchr(component->name_prefix, '-');
+             unsigned long idx;
+
+             if (idx_str && !kstrtoul(idx_str + 1, 10, &idx) && idx)
+                     port_config.ch_mask = (idx & 1) ? BIT(0) : BIT(1);
+     }
+
       /* port 1 for playback */
       if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
               port_config.num = 1;
--
2.53.0


On 7/27/26 10:48, Andrey Golovko wrote:
> Hi Antoine,
>
> Confirmed on a second machine: ASUS ProArt PX13 HN7306EAC (Ryzen AI MAX+
> 395), Ubuntu 26.04, 7.2-rc4 based kernel, same two TAS2783 at unique_id
> 0x8 / 0xB plus RT721 on SoundWire link 1.
>
> Rather than judging by ear, I used the per-amp mixer controls, which
> makes the result unambiguous. Both amps at full scale ('tas2783-1/-2 Amp
> Volume' = 20, 'Speaker Volume' = 200), all four 'Left/Right Spk[2]
> Switch' on:
>
>    speaker-test -Dpipewire -c2 -s1 (left channel only)
>      - audible
>      - 'tas2783-2 Speaker Volume' = 0  -> complete silence
>      - 'tas2783-1 Speaker Volume' = 0  -> no audible change
>
>    speaker-test -Dpipewire -c2 -s2 (right channel only)
>      - silent, with both amps unmuted at full scale
>
> So exactly your picture: one amp (tas2783-2) renders audio and it renders
> the *left* channel, the other amp contributes nothing, and the right
> channel is never reproduced. Both amps do load their own per-address
> blob here (1714-1-8.bin / 1714-1-B.bin, via the fallback naming path
> after the 0x-prefixed names miss), so this is not a case of the wrong
> configuration being downloaded.
>
> On the "proper mechanism" question: a good part of the plumbing already
> exists, and it does not need unique_id at all.
>
>   - The machine layer already knows which amp is which. In
>     sound/soc/sdw_utils/soc_sdw_ti_amp.c, asoc_sdw_ti_spk_rtd_init() maps
>     the component name prefix to a speaker widget: tas2783-1 -> "Left
>     Spk", tas2783-2 -> "Right Spk", tas2783-3/-4 -> "Left/Right Spk2".
>     That is where the four 'Left/Right Spk[2] Switch' controls on this
>     board come from.
>
>   - asoc_sdw_hw_params() (sound/soc/sdw_utils/soc_sdw_utils.c) fills
>     dai_link->ch_maps, but for playback it deliberately hands every codec
>     the full mask ("Identical data will be sent to all codecs in
>     playback"), leaving the per-amp channel selection to the amp itself.
>     acp-sdw-legacy-mach, which drives this board, uses both.
>
> So the driver could derive the channel from the same prefix index the
> DAPM routing already uses, or from its entry in dai_link->ch_maps,
> instead of hard-coding SoundWire addresses.
>
> Which raises the question for TI: on TAS2783 is the channel selection
> meant to come from the per-device .bin (in which case it is evidently
> not taking effect on this board), or is the driver expected to program a
> per-amp channel mask? Depending on the answer, either the firmware
> description or tas_sdw_hw_params() needs fixing - and in the latter case
> the amp's channel should come from the machine-level mapping rather than
> from unique_id, which as you say is board-specific.
>
> Happy to test patches on this hardware; I can also collect register
> dumps from both amps if that helps.
>
> Thanks,
> Andrey