On 2018年10月02日 18:50, Georg Chini wrote:
Yes, configurable enable/disable detection on per-card, per-port and/or per-jack-element basis is a better idea.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:Got it, I will take some time to understand your plan first, then have aOn Sun, 2018-09-30 at 15:03 +0800, Hui Wang wrote:This issue is also reported to: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/579Recently 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 alsohas 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-speaker6. open sound-setting (gnome-control-center --> choose sound), you willsee two output devies: speaker and HDMI audio7. 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 wereplug a monitor with audio capability then the speaker-test outputfrom 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, analogdevices on one card, hdmi audio on the other card. This kind of laptopsare 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 andUSB 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 portor 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 hasavailble 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-restoreshould 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?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.
_______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss