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

[Andrey Golovko]

On 7/27/26 13:21, Antoine Monnet wrote:
> 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.

Tested-by: Andrey Golovko <andrey@xxxxxxxxxx>

Confirmed on the second machine: ASUS ProArt PX13 HN7306EAC, v7.2-rc4 based
kernel, same two TAS2783 at unique_id 0x8 / 0xB plus RT721 on SoundWire
link 1.

With your patch applied both amps render, and the assignment is correct by
physical placement, not merely by control name:

  speaker-test -Dpipewire -c2 -s1  ->  physically left speaker only
  speaker-test -Dpipewire -c2 -s2  ->  physically right speaker only

Both amps at full scale, all four Left/Right Spk[2] switches on. Before the
patch, -s1 was audible and -s2 was silent, with only one amp contributing at
all - so this is exactly the behaviour you predicted for an identical
HN7306EAC: the prefix ordering matches, tas2783-1 takes the left channel and
tas2783-2 the right, and that lines up with the physical speakers.

One caveat, measured since by Robin Everaars, who reported the same
issue on yet another HN7306EAC (added to Cc):

  https://lore.kernel.org/all/20260805183517.8665-1-robineveraars@xxxxx/

The ch_mask *value* is not what selects the channel:
sdw_compute_slave_ports() assigns payload offsets positionally along
slave_rt_list, and Robin showed that inverting the two masks between the
amps does not move the audio. A one-channel mask fixes mono because it
stops the mirror-mode offset reset; L/R then follows the codec order in
the DAI link, which on this platform happens to match the speakers. The
Tested-by stands - the split the patch produces is correct on both
machines - but the name_prefix -> BIT(n) mapping reads as if the bit
picks the channel, which is worth a comment or a reword before a formal
submission. Where the binding should really come from is being discussed
in Robin's thread.

Thanks,
Andrey