Issue metadata
Sign in to add a comment
|
[regression] PULSE_SINK variable ignored
Reported by
virus.fl...@gmail.com,
Sep 4
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/69.0.3497.72 Chrome/69.0.3497.72 Safari/537.36 Example URL: Steps to reproduce the problem: See man pulseaudio | grep PULSE_ Regression is: On Chromium <69: $ pactl load-module module-null-sink sink_name="wirec_test" sink_properties=device.description="wirec_test" $ env PULSE_SINK="wirec_test" chromium-browser Play some sound in Chromium. Then open pavucontrol and see that sound is outputed to the palyback device "wirec_test" as set by PULSE_SINK environmental variable. Regression: this variable is ignored in Chromium 69 and 70. I use PULSE_* variables in production in my scripts https://gitlab.com/mikhailnov/dumacast https://gitlab.com/mikhailnov/wirec What is the expected behavior? What went wrong? . Did this work before? N/A Is it a problem with Flash or HTML5? N/A Does this work in other browsers? N/A Chrome version: 69.0.3497.72 Channel: beta OS Version: Flash Version: Contents of chrome://gpu:
,
Sep 4
,
Sep 4
Hmm, I don't remember any pulse audio changes in that time period that would have broken this.
,
Sep 4
I also thought that it might be due to that I updated PulseAudio, but no, on the same system I tried Chromium 68 and Falkon (QtWebengine with older Chromium) from Ubuntu repositories, and everything works. It regressed on version 69. libpulse API and ABI did not change: https://abi-laboratory.pro/index.php?view=timeline&l=pulseaudio
,
Sep 5
Wild guess is that env variables doesn't propagate to the utility process. I'll check.
,
Sep 5
The env is propagated. Most likely the cause is https://chromium-review.googlesource.com/c/chromium/src/+/1072649, where we map "default" to whatever the actual default device id is (https://cs.chromium.org/chromium/src/media/audio/audio_manager_base.cc?sq=package:chromium&g=0&l=326). I guess PULSE_SINK must be taken into account when determining the "real default device". Guido: Could you take a look?
,
Sep 5
Tried testing the issue by navigating to the URL's provided in comment# 0(https://gitlab.com/mikhailnov/dumacast & https://gitlab.com/mikhailnov/wirec) and downloaded the zip file from the download link, but didn't find any file that used to test and confirm the issue. @Reporter: Could you please provide manual reproducible steps or Test file/URL with actual and excepted behaviour which helps us in further triaging the issue in better way. Thanks!
,
Sep 5
,
Sep 5
viswa.karala@, I already provided steps to reproduce it in #0. dumacast and wirec are just examples of scripts where I use PULSE_*. E.g. in Wirec I open Chromium in Xephyr, output the sound to a fake output device, the user on the workstation does not hear the sound, but it's recorded by ffmpeg. Regression is: On Chromium <69: $ pactl load-module module-null-sink sink_name="wirec_test" sink_properties=device.description="wirec_test" $ env PULSE_SINK="wirec_test" chromium-browser Play some sound in Chromium. You must not hear it. Then open pavucontrol and see that sound is outputed to the palyback device "wirec_test" as set by PULSE_SINK environmental variable. That's why you don't hear the sound. Regression: this variable is ignored in Chromium 69 and 70. wirec_test will not be set as an output device.
,
Sep 6
I don't think we should fix this. The devices that we use as default are the ones reported by pulse audio as default. An alternative to using the variables is to set the default sink using pactl set-default-sink wirec_test
,
Sep 7
$ git clone https://github.com/pulseaudio/pulseaudio.git cd pulseaudio $ grep -inHr PULSE_SINK src/modules/module-tunnel.c:65:#define ENV_DEFAULT_SINK "PULSE_SINK" ----------- From src/pulse/client-conf.c : static void load_env(pa_client_conf *c) { char *e; if ((e = getenv(ENV_DEFAULT_SINK))) { pa_xfree(c->default_sink); c->default_sink = pa_xstrdup(e); } ---------- @guidou, So, PulseAudio seems to use $PULSE_SINK as a default device if libpulse's client does not specify any other sink manually. Please, fix it...
,
Sep 7
Even Firefox respects PULSE_SINK for sound output. But Firefox never respected PULSE_SOURCE because it has a strange way of setting up sound input devices.
,
Sep 7
https://freedesktop.org/software/pulseaudio/doxygen/simple.html s = pa_simple_new(NULL, // Use the default server. "Fooapp", // Our application's name. PA_STREAM_PLAYBACK, NULL, // Use the default device. > NULL, // Use the default device.
,
Sep 7
In Chromium <=68 chrome://settings/content/microphone had just "Default microphone"
,
Sep 7
In Chrome >= 69 chrome://settings/content/microphone has "Default device - %NAME%", where %NAME% is PulseAudio's default output device. So, this usability change broke Chromium for advanced users who wanted to route sound specially. Please, revert this!
,
Sep 7
#14: That's just a change in the label independent of the mechanism we use to determine the default device.
,
Sep 7
First off, we are not going to revert any change, since the changes that introduced this behavior change are required to support Web specs. We are evaluating if it makes sense to manually add support for PULSE_SINK/PULSE_SOURCE. If list-sinks reports as default a device that is different from that specified in PULSE_SINK, then it seems to me that this is a bug in pulse and not in Chrome. You can also update your scripts to change the default device using pactl instead of using PULSE_SINK.
,
Sep 7
,
Sep 7
> You can also update your scripts to change the default device using pactl instead of using PULSE_SINK. I want to start only ONE application with another source or sink and not change it system-wide. > If list-sinks reports as default a device that is different from that specified in PULSE_SINK Probably not. PulseAudio's daemon reports user/systemd wide default sink, not per application. > We are evaluating if it makes sense to manually add support for PULSE_SINK/PULSE_SOURCE. But Chromium < 69 did have support for it. It broke in 69.
,
Sep 7
Chromium < 69 supported it largely by accident. We were not telling pulse to use the device it considered default, but instead we were telling it to use the empty string. Maybe some code path in pulse interprets the empty string as trying PULSE_SINK if it exists. The old approach made it impossible to support some standard Web specs, such as the groupId constrainable property in getUserMedia(), since we were not really aware of what the real default device (according to the system) was. Still, we are evaluating if we should manually add support for PULSE_SINK/PULSE_SOURCE (or only PULSE_SINK).
,
Sep 7
Looking at PulseAudio documentation, this seems to be a PulseAudio bug. Default devices and how they are set is documented here: https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/DefaultDevice/ It does not mention PULSE_SINK, and Chrome works according to what is mentioned there. However, in https://www.freedesktop.org/wiki/Software/PulseAudio/FAQ/#index5h3 it is stated that PULSE_SINK represents the default sink. These two things appear to be in conflict. virus.flute.pr@: Can you file a PulseAudio bug so that we can get clarification from the PulseAudio team? I would prefer to solve this problem relying entirely on PulseAudio and not by having Chrome manually inspect the PULSE_SINK environment variable.
,
Sep 7
I just filed PulseAudio issue https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/573 explaining the change in Chromium and asking for clarifications.
,
Sep 7
Ok. I've never filed bugs to PulseAudio, but once wrote to pulseaudio-dev@ mailing list and PA's developers sent a patch very quickly (thanks to them again).
,
Sep 7
,
Sep 10
Hello. I'll comment on this bug, since it seems like it could be the same root cause as the bug I'm noticing. pavucontrol can be used to control which output device is used for a playback stream. This change is saved so that when a stream stops and starts again, PulseAudio restores the output device that was used previously (unless the program specifies the device to use). So the bug is as follows: 1) Have chrome play some audio 2) In pavucontrol, switch the output device used for chrome's playback stream to something other than the fallback device 3) Stop the audio in chrome 4) Wait for chrome's entry in pavucontrol to go away 5) Have chrome play audio again What is the expected result? Chrome uses the device that was saved for its stream What happens instead? Chrome uses the fallback device This regressed in 69.
,
Sep 10
That's a good notice. "We are evaluating if it makes sense to manually add support for PULSE_SINK/PULSE_SOURCE" — manual support for PULSE_SOURCE and PULSE_SINK environmental variables will not help to restore previous behaviour as mcnee@ noticed, because they are not set by default. "The old approach made it impossible to support some standard Web specs, such as the groupId constrainable property in getUserMedia(), since we were not really aware of what the real default device (according to the system) was." In general personally I was OK when it was named just 'Default device', but users who do not know PulseAudio's behaviour may be not OK.
,
Sep 10
Also, when module-switch-on-connect is active, and it's active by default in Ubuntu >= 17.10, PulseAudio should behave like this: 1) I had no USB microphone connected (USB webcam is a typical usb microphone, a bluetooth device is the same behaviour) 2) Started audio input to Chromium, it started with non-USB microphone 3) Connected USB microphone 4) module-switch-on-connect will make the new USB microphone a default input device 5) module-switch-on-connect will switch all (all? or only where output device was not strictly specified?) active pulseaudio's input streams to use the new USB microphone, Chromium's <69 input stream as well will be switched without stopping it 6) disconnect USB microphone 7) input streams will be automatically switched back to the old device Questions: 1) how will this work in Chromium >= 69 with new behaviour? 2) what will happen if I start a recording in Chromium from USB microphone and disconnect it during the recording? In Chromium <69 it should be automatically switched to another input device, e.g. analog microphone built-in in the notebook. Will the recording contnue once the USB microphone is reconnected? Please note that in PulseAudio 12 module-switch-on-connect behaviour was changed for virtual sinks, that's not a case for Chromium, but it shows that this mosule is under active development. Pulseaudio developers made this change after we asked for it in pulseaudio-discuss@ (https://github.com/wwmm/pulseeffects/issues/99).
,
Sep 10
Wrote to pulseaudio-discuss@: https://lists.freedesktop.org/archives/pulseaudio-discuss/2018-September/030479.html
,
Sep 26
We have decided to restore the old behavior for audio output, but will keep the new behavior for input, at least for now. This restores expected pulse functionality while maintaining W3C spec compliance.
,
Sep 26
,
Sep 26
This means PULSE_SINK will no longer be ignored if the default device is selected in Chrome.
,
Sep 26
,
Sep 26
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/41214a8f0d4dc8569a4a60b7a8c7f5d0cd93f7ed commit 41214a8f0d4dc8569a4a60b7a8c7f5d0cd93f7ed Author: Guido Urdaneta <guidou@chromium.org> Date: Wed Sep 26 08:57:18 2018 Do not use the fallback output device as default in Pulse Audio. The concept of default device in Pulse Audio is not very clear. What the Pulse API reports as default device is actually a fallback device to be used if no specific device is requested and the PULSE_SINK environment variable has not been set. A previous change to AudioManagerPulse made Chromium use the default device reported by Pulse as default, which has caused problems for users relying on PULSE_SINK. A similar issue exists with the default input device and the PULSE_SOURCE environment variable, but this CL does not address the input case for two reasons: 1. Failing to recognize (and request) a specific default device makes it difficult to properly support the groupId constrainable property in getUserMedia(). 2. Unlike PULSE_SINK, no issues have been reported so far with regards to the use of the default input device and PULSE_SOURCE. If such issues arise, it will be handled separately. Bug: 880180 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel Change-Id: I584b994f2dbd3a4da305bf25f513223af2478ca0 Reviewed-on: https://chromium-review.googlesource.com/1243183 Reviewed-by: Max Morin <maxmorin@chromium.org> Commit-Queue: Guido Urdaneta <guidou@chromium.org> Cr-Commit-Position: refs/heads/master@{#594257} [modify] https://crrev.com/41214a8f0d4dc8569a4a60b7a8c7f5d0cd93f7ed/media/audio/pulse/audio_manager_pulse.cc
,
Sep 26
,
Sep 26
> 2. Unlike PULSE_SINK, no issues have been reported so far with regards > to the use of the default input device and PULSE_SOURCE. If such issues > arise, it will be handled separately. Well, I have another use-case (https://gitlab.com/mikhailnov/dumacast/blob/master/usr/bin/dumacast) where PULSE_SOURCE is used to set input device. A video is played locally, it's picture is sent to a virtual webcam (v4l2loopback) and it's sound is joined with the microphone and sent to Chromium. The script automatically launches Chromium with virtual microphone in PULSE_SOURCE. The purpose is to show a pre-recorded video with sound on the webinar, where the webinar platform does not support playing videos. I did not test it with Chromium 69 and so did not write about PULSE_SOURCE in the title of this issue.
,
Sep 26
Should I make a new issue?
,
Sep 26
File a new one, since we already closed this one. And also test upcoming canaries to verify the PULSE_SINK issue.
,
Sep 27
Sorry, there are no Canaries on Linux, so you'll have to wait for the next dev version to test the fix.
,
Oct 2
,
Oct 2
This bug requires manual review: We are only 13 days from stable. Please contact the milestone owner if you have questions. Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 2
Hello. I've updated past that CL and can confirm that the issue I described in c#25 is resolved on ToT. Thanks.
,
Oct 5
,
Oct 6
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/26dfe7728c07a94c98381a431714bb9627144efe commit 26dfe7728c07a94c98381a431714bb9627144efe Author: Guido Urdaneta <guidou@chromium.org> Date: Sat Oct 06 08:20:22 2018 Do not use the fallback output device as default in Pulse Audio. The concept of default device in Pulse Audio is not very clear. What the Pulse API reports as default device is actually a fallback device to be used if no specific device is requested and the PULSE_SINK environment variable has not been set. A previous change to AudioManagerPulse made Chromium use the default device reported by Pulse as default, which has caused problems for users relying on PULSE_SINK. A similar issue exists with the default input device and the PULSE_SOURCE environment variable, but this CL does not address the input case for two reasons: 1. Failing to recognize (and request) a specific default device makes it difficult to properly support the groupId constrainable property in getUserMedia(). 2. Unlike PULSE_SINK, no issues have been reported so far with regards to the use of the default input device and PULSE_SOURCE. If such issues arise, it will be handled separately. Bug: 880180 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel Change-Id: I584b994f2dbd3a4da305bf25f513223af2478ca0 Reviewed-on: https://chromium-review.googlesource.com/1243183 Reviewed-by: Max Morin <maxmorin@chromium.org> Commit-Queue: Guido Urdaneta <guidou@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#594257}(cherry picked from commit 41214a8f0d4dc8569a4a60b7a8c7f5d0cd93f7ed) Reviewed-on: https://chromium-review.googlesource.com/c/1267075 Reviewed-by: Guido Urdaneta <guidou@chromium.org> Cr-Commit-Position: refs/branch-heads/3538@{#883} Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811} [modify] https://crrev.com/26dfe7728c07a94c98381a431714bb9627144efe/media/audio/pulse/audio_manager_pulse.cc
,
Oct 6
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/26dfe7728c07a94c98381a431714bb9627144efe Commit: 26dfe7728c07a94c98381a431714bb9627144efe Author: guidou@chromium.org Commiter: guidou@chromium.org Date: 2018-10-06 08:20:22 +0000 UTC Do not use the fallback output device as default in Pulse Audio. The concept of default device in Pulse Audio is not very clear. What the Pulse API reports as default device is actually a fallback device to be used if no specific device is requested and the PULSE_SINK environment variable has not been set. A previous change to AudioManagerPulse made Chromium use the default device reported by Pulse as default, which has caused problems for users relying on PULSE_SINK. A similar issue exists with the default input device and the PULSE_SOURCE environment variable, but this CL does not address the input case for two reasons: 1. Failing to recognize (and request) a specific default device makes it difficult to properly support the groupId constrainable property in getUserMedia(). 2. Unlike PULSE_SINK, no issues have been reported so far with regards to the use of the default input device and PULSE_SOURCE. If such issues arise, it will be handled separately. Bug: 880180 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel Change-Id: I584b994f2dbd3a4da305bf25f513223af2478ca0 Reviewed-on: https://chromium-review.googlesource.com/1243183 Reviewed-by: Max Morin <maxmorin@chromium.org> Commit-Queue: Guido Urdaneta <guidou@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#594257}(cherry picked from commit 41214a8f0d4dc8569a4a60b7a8c7f5d0cd93f7ed) Reviewed-on: https://chromium-review.googlesource.com/c/1267075 Reviewed-by: Guido Urdaneta <guidou@chromium.org> Cr-Commit-Position: refs/branch-heads/3538@{#883} Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
,
Oct 10
Tested this issue on Ubuntu 14.04 on the build without fix 69.0.3497.100 and unable to reproduce the issue by following the steps mentioned in duped issue 884160 . 1. On Ubuntu 14.04, installed the PulseAudio Volume Control software. 2. Played a video on Youtube.com and changed the audio channel of Chrome from default to Headphones 3. Restarted the video and could observe that the audio channel of Chrome is not reset to default. Attached is the screen cast for reference. guidou@ Request you to check and confirm if anything is missed from our end in verifying the issue and help us in verifying the fix on the latest M-70 build. Thanks.
,
Oct 10
susan.boorgula@: Check if you set the PULSE_SINK environment variable to some valid device that is not the fallback device. If you only have one audio device, you can create fake ones with, for example, pactl load-module module-null-sink sink_name="wirec_test" sink_properties=device.description="wirec_test"
,
Dec 20
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by virus.fl...@gmail.com
, Sep 4