[pulseaudio-discuss] Audio APP (sink-input) bind to the sink with only unplugged hdmi-audio ports on it

Tue Oct 2 10:50:11 UTC 2018

On 02.10.2018 11:49, Tanu Kaskinen wrote:
> On Mon, 2018-10-01 at 10:18 +0800, Hui Wang wrote:
>> On 2018年09月30日 18:30, Tanu Kaskinen wrote:
>>> On Sun, 2018-09-30 at 15:03 +0800, Hui Wang wrote:
>>>> This issue is also reported to:
>>>> https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/579
>>>>
>>>> Recently we found a weird issue on many laptops with the ubuntu 18.04,
>>>> it uses the pulseaudio-11.1 (I guess the PA of the latest version also
>>>> has this problem). The issue is like this:
>>>>
>>>>    1. boot the system up without plugging a hdmi monitor
>>>>    2. run an audio app to play sound (e.g. $speaker-test)
>>>>    3. the sound outputs from analog-speaker
>>>>    4. plug a monitor with audio capability (through DP or HDMI port)
>>>>    5. the sound still outputs from analog-speaker
>>>>    6. open sound-setting (gnome-control-center --> choose sound), you will
>>>>       see two output devies: speaker and HDMI audio
>>>>    7. choose HDMI audio, the sound will switch to HDIM audio from speaker
>>>>       (pa will remember speaker-test prefer to use hdmi-audio sink)
>>>>    8. unplug the monitor, the default-sink is switching to analog-speaker,
>>>>       but the sound of speaker-test still route to hdmi-audio sink
>>>>    9. run other sound apps, they all route sound to default sink
>>>>       (analog-speaker), but speaker-test always routes to hdmi-audio sink,
>>>>       as a result, speaker-test can't output sound anymore unless we
>>>>       replug a monitor with audio capability then the speaker-test output
>>>>       from hdmi-audio again.
>>>> 10. if we want the speaker-test to route to analog-speaker, two ways:
>>>>       run pacmd move-sink-input or plug a monitor, after two audio devices
>>>>       (hdmi audio and speaker) show up in the sound-setting, select
>>>>       analog-speaker manually.
>>>>
>>>> This issue only happens on the laptops with 2 audio cards, analog
>>>> devices on one card, hdmi audio on the other card. This kind of laptops
>>>> are very common, like I+A (Intel graphic + Amd Graphic), I+N(Intel +
>>>> Nvidia), and A AMD.
>>>>
>>>> This issue will not happen on the laptops with only Intel graphic card,
>>>> since both analog and hdmi audio belong to one sound card. When hdmi
>>>> monitor is unplugged, the hdmi sink will be removed from PA, then all
>>>> sink-inputs will route to the only left sink: analog-sink.
>>>>
>>>> This issue will not happen on BT or USB audio. Unlike hdmi audio, BT and
>>>> USB audio cards will be removed totally from PA when they are
>>>> unpluged/unconnected, so they don't have this issue as well.
>>>>
>>>> The root cause of this issue is although the hdmi monitor is unplugged,
>>>> the hdmi-sink still exists, and sink-input is selected by user to bind
>>>> to this sink, so the pa doesn't care about if this sink has valid port
>>>> or not, it bind the sink-input to this sink unconditionally.
>>>>
>>>> Maybe we could improve it like this: if the user selected sink only has
>>>> available_no ports, the pa will switch all sink-inputs of this sink to
>>>> other sinks (like default_sink) temporarily, once the selected sink has
>>>> availble ports, all sink-inputs switch back to this sink.
>>>>
>>>> Any good ideas?
>>> The plan has been to do the following (but I haven't found the time to
>>> implement it):
>>>
>>> Streams currently have a "save_sink" flag that tells whether the
>>> current sink should be remembered and restored by module-stream-
>>> restore. That flag should be replaced with a "preferred_sink" string
>>> that is set when the user moves the stream. module-stream-restore
>>> should remember and restore that string.
>>>
>>> When the user moves a stream to the current default sink, the
>>> "preferred_sink" string should be set to NULL and module-stream-restore
>>> should clear the routing for that stream in the stream database. From
>>> that point on the stream will be always routed to the default sink.
>>>
>>> When a stream is created, module-stream-restore should set the
>>> "preferred_sink" string and if that sink exists, the core should set
>>> that sink as the initial routing for the new stream.
>>>
>>> When the default sink changes, the streams from the old default sink
>>> should be moved to the new default sink, unless the "preferred_sink"
>>> string is set to the old default sink and the active port of the old
>>> default sink is not unavailable. This should be done by the core.
>>>
>>> When the active port of a sink becomes unavailable, all streams from
>>> that sink should be moved to the default sink. This should be done by
>>> the core.
>>>
>>> When a new sink appears or the active port of an existing sink changes
>>> state from unavailable, all streams that have their "preferred_sink"
>>> set to the new sink should be moved to the new sink. This should be
>>> done by the core.
>>>
>>> As a result, module-stream-restore doesn't need to move streams any
>>> more, it only needs to manage the "preferred_sink" variables. Some
>>> other modules can perhaps be simplified as well.
>>>
>>> The same logic should of course be implemented for capture streams as
>>> well.
>>>
>>> Would you be willing to implement this?
>>>
>> Got it, I will take some time to understand your plan first, then have a
>> try to implement it.
> Maybe this rephrasing will help with understanding, maybe not:
>
> The idea is to store the preferred routing in the core pa_sink_input
> struct instead of hiding that information in module-stream-restore. The
> core should then take care to ensure that streams are always routed to
> their preferred sinks, or if the preferred sink is not set or not
> available, then to the default sink.
>
> There are some exceptions:
>
> If a sink's active port is unavailable, no streams should be routed to
> it, unless it's the default sink (and it shouldn't be the default sink
> unless all sinks are similarly unavailable). [1]
>
> An application may request a particular sink when it creates a stream.
> The request should be honored, but the preferred_sink variable should
> not be affected by the application request. The requested initial
> routing should be treated as a temporary override.
>
> Some policy modules may move streams temporarily to a sink that is
> neither the default sink nor the stream's preferred sink. For example,
> module-allow-passthrough creates a null sink for streams that are moved
> away from the "main sink" when a passthrough stream needs to access the
> main sink. Those policy modules need to continue working.
>
>
> [1] I'm afraid this requires us to provide a way to disable jack
> detection, because on some hardware the jack detection doesn't work
> properly, and ports are marked as unavailable when they shouldn't be.
> If a port is incorrectly marked as unavailable, the proposed logic
> makes it impossible to play anything to it. So this is some extra
> work... Disabling jack detection could be implemented as an argument to
> module-udev-detect (and module-alsa-card) that would affect all ports
> on all alsa cards, but it would be better to have a configuration file
> (I'm thinking /etc/pulse/alsa.conf) where the jack detection could be
> disabled on per-card, per-port and/or per-jack-element basis.
>
There are already some patches to enable/disable jack detection,
but they are using the messaging interface which is not yet in the
tree.