On 23/04/2024 12:59, Johan Hovold wrote:
On Mon, Apr 22, 2024 at 02:43:50PM +0100, Srinivas Kandagatla wrote:
From: Srinivas Kandagatla <srinivas.kandagatla@xxxxxxxxxx>
This patchset adds support for.
1. parse Display Port module tokens from ASoC topology
2. add support to DP/HDMI Jack events.
3. fixes a typo in function name in sm8250
Verified these patches on X13s along with changes to tplg in
https://git.codelinaro.org/linaro/qcomlt/audioreach-topology/-/tree/topic/x13s-dp?ref_type=heads
and ucm changes from https://github.com/Srinivas-Kandagatla/alsa-ucm-conf/tree/topic/x13s-dp
It looks like your UCM changes are still muxing the speaker and *each*
displayport output so that you can only use one device at a time (i.e.
only Speaker or DP1 or DP2 can be used).
that is true.
What is the use-case to use more than one audio sink devices at the same
time for a laptops?
How do you test it? I never tested anything like that on a full desktop
setup.
May be some manual setup in Wireplumber, but not 100% sure about
multiple stream handling.
As we discussed off list last week, this seems unnecessarily limited and
as far as I understood is mostly needed to work around some
implementation details (not sure why DP1 and DP2 can't be used in
parallel either).
It is absolutely possible to run all the streams in parallel from the
Audio hardware and DSP point of view.
One thing to note is, On Qualcomm DP IP, we can not read/write registers
if the DP port is not connected, which means that we can not send data
in such cases.
This makes it challenging to work with sound-servers like pipewire or
pulseaudio as they tend to send silence data at very early stages in the
full system boot up, ignoring state of the Jack events.
Can you please describe the problem here so that we can discuss this
before merging an unnecessarily restricted solution which may later be
harder to change (e.g. as kernel, topology and ucm may again need to be
updated in lock step).
From what I could tell after a quick look, this series does not
necessarily depend on muxing things this way, but please confirm that
too.
These patches have nothing to do with how we model the muxing in UCM or
in tplg.
so these can go as it is irrespective of how we want to model the DP
sinks in the UCM or tplg.
--srini
Johan
