Message-ID: <a86b51fa-20c0-4ba0-a3b8-c8ac9cd3b433@perex.cz>
Date: Sun, 9 Nov 2025 12:43:07 +0100
From: Jaroslav Kysela <perex@...ex.cz>
To: Takashi Iwai <tiwai@...e.de>,
 Srinivas Kandagatla <srinivas.kandagatla@....qualcomm.com>
Cc: Mark Brown <broonie@...nel.org>, Takashi Iwai <tiwai@...e.com>,
 linux-sound <linux-sound@...r.kernel.org>, wtaymans@...hat.com,
 arun@...mptotic.io, lkml <linux-kernel@...r.kernel.org>,
 Krzysztof Kozlowski <krzk@...nel.org>,
 Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Subject: Re: DP/HDMI Jack and Pipewire

On 11/8/25 10:21, Takashi Iwai wrote:
> On Fri, 07 Nov 2025 11:15:50 +0100,
> Srinivas Kandagatla wrote:
>>
>> Hi Everyone,
>>
>> On Qualcomm platforms we have an issue enabling Display port on a full
>> Distro setup with pipewire and wireplumber in place.
>>
>> The issue is that Display port Audio IP on Qualcomm SoC is powered off
>> if there is no Display connected. It make sense to keep it in this low
>> power mode when there is no use. And the DP IP is not expecting any data
>> in this state and any attempt to configure or send data would result in
>> error from DSP.
>>
>> However, we create PCM devices and jacks for all audio sinks and
>> sources, including DisplayPort DAI links. When PipeWire starts up
>> without any awareness of jack state it probes all available PCM devices,
>> including the DisplayPort ones. Since no display is connected, the
>> prepare callback for DP fails, leading PipeWire to mark the sound card
>> as unusable. Consequently, it abandons entire sound card, including
>> other valid audio sinks. I have also started discussing this issue with
>> pipewire [1]
>>
>>
>> What is the expected pcm device behavior when DP jack is not connected?
>>
>> Two possibilities:
>>
>> 1. Consume the data even when the Display is not connected. I see that
>> in Intel case it sinks the data somewhere and gives the user an
>> experience that the data is getting consumed.
>>
>> 2. Throw an error to user if they attempt to configure or send the data
>> to this disconnected pcm.
>>
>>
>> Also what userspace ABI to for such usecase?
>>
>> This is blocking end-to-end DP audio enablement on Qualcomm SoCs.
>>
>> Not sure if this is right approach or will work but somehow we back the
>> pcm devices with disconnected jack state to use dummy pcm ops instead of
>> actual pcm ops?
>> This should at least keep the pipewire happy. Is this the right approach?
>>
>>
>> [1]: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4938
>>
>> Thanks,
>> Srini
> 
> I believe this has been a long-standing problem even for HD-audio.
> The HD-audio HDMI driver does open and process without actual pin
> setup for allowing the probe by PA/PW with the assumption of some
> basic PCM parameters.  It was introduced in the commit
> 42b2987079eca0238b576c08af1144ed5bd52188
>      ALSA: hda - hdmi playback without monitor in dynamic pcm bind mode
> 
> So I find using a dummy ops would make sense (assuming it's actually
> enough to convince PA/PW).

Or the pipewire/pulseaudio should not go beyond SNDRV_PCM_STATE_SETUP for 
probing and just do enumeration using hw parameters given from the driver. At 
least for UCM, the devices should be defined properly. PW/PA should allow open 
only when the associated Jack control signalized the availability of the PCM 
device.

IMHO it's not reponsibility for the kernel driver to accept such incorrect 
scenarios. The PCM API is straight for this.

					Jaroslav

-- 
Jaroslav Kysela <perex@...ex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Powered by blists - more mailing lists