Re: [pulseaudio-discuss] Disabling PulseAudio direct access to ALSA devices
On 06 May, 2020 - S. wrote: > On Wed May 6 17:51:53 UTC 2020 Anton Lundin wrote: > > > I'd suggest a workaround, like loading a module-remap-source without a > > remap, that just wraps your source, and then the AGC can pull that source > > to 100% volume without touching the underlying source. > > That makes sense. Any implementation tips or links perchance? Thanks a lot. pactl load-module module-remap-source start pavucontrol and move the recording for your module-remap-source to your mic and move your chromium apps recording to your remapped source. //Anton ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Disabling PulseAudio direct access to ALSA devices
On Wed May 6 17:51:53 UTC 2020 Anton Lundin wrote: Chrome AGC works just fine for alot of people in a bunch of different scenarios. AGC over all can be a bit tricky but calling it "buggy in anything based on Chromium" is a big stretch. Just because it doesn't work as you expect doesn't mean that its broken for everyone. Sorry, what I meant was that anything based on Chromium exhibits this same bug *for me*. So my point is that for my needs there is no workaround by simply using a different browser, given that most VoIP apps are coded for Chrome(ium)'s specific WebRTC implementation and/or wrapped into Electron which is also Chromium based. (There are indeed many unhandled bug reports with very large numbers of users reporting the same issue on Chrome and Chromium's bug trackers, but that's extraneous to this list.) I'd suggest a workaround, like loading a module-remap-source without a remap, that just wraps your source, and then the AGC can pull that source to 100% volume without touching the underlying source. That makes sense. Any implementation tips or links perchance? Thanks a lot. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Disabling PulseAudio direct access to ALSA devices
On 06 May, 2020 - S. wrote: > Hi there, recently I've been running into major problems with Electron apps > for the Linux desktop (Microsoft Teams and Riot.im) modifying my mic input > levels. Also Chromium/Chrome do the same thing during WebRTC calls, they > raise my mic level to 100%, thus completely saturating the audio and making > it unusable. I drop it back down manually, but within a few seconds it creeps > back up to 100% again. In my case it tries to max out the mic gain, but I've > read lots of other user reports where it tries to lower the user's mic gain > to an unusable level. I'm guessing that something doesn't report the right levels on your alsa source. It's a tricky thing to measure and figure out where the bug might be, but you can always look for obvious faults. > > Sometimes this is the result of a "smart" VoIP program like Skype that has an > option to allow the program to adjust the audio device levels. But my problem > is that all my VoIP apps use WebRTC, which appears to include its own > implementation of AGC as part of the protocol, and it's obviously buggy in > anything based on Chromium (Chrome, electron apps, etc.), and there's no way > to disable it. There have been bug reports to Chrome(ium) for years about > this and they obviously don't care. Firefox doesn't exhibit this behavior, > but unfortunately a lot of WebRTC apps are either Electron (based on > Chromium) or else don't support Firefox very well. Ultimately, I think this > behavior should be controllable via PulseAudio, since we can never assume all > apps with have sane behavior. Chrome AGC works just fine for alot of people in a bunch of different scenarios. AGC over all can be a bit tricky but calling it "buggy in anything based on Chromium" is a big stretch. Just because it doesn't work as you expect doesn't mean that its broken for everyone. > > In Windows there's an option to not allow programs to control a specific > device. I think we also desperately need a PulseAudio option to disable > direct access to the audio hardware. It appears this should be possible in > `/usr/share/pulseaudio/alsa-mixer/paths/analog-input-internal-mic.conf` by > changing `volume = merge` to `volume = off` or `volume = XX` according to > what I've read. But since the profiles are under `/usr/share/` they're > obviously not meant to be user configurable, which I think should be changed. > > I'd really appreciate it if you could make this behavior user-configurable, > possibly by looking for the profiles somewhere under `/etc/pulse` and/or > `~/.config/pulse/`. > I'd suggest a workaround, like loading a module-remap-source without a remap, that just wraps your source, and then the AGC can pull that source to 100% volume without touching the underlying source. //Anton ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Disabling PulseAudio direct access to ALSA devices
Hi there, recently I've been running into major problems with Electron apps for the Linux desktop (Microsoft Teams and Riot.im) modifying my mic input levels. Also Chromium/Chrome do the same thing during WebRTC calls, they raise my mic level to 100%, thus completely saturating the audio and making it unusable. I drop it back down manually, but within a few seconds it creeps back up to 100% again. In my case it tries to max out the mic gain, but I've read lots of other user reports where it tries to lower the user's mic gain to an unusable level. Sometimes this is the result of a "smart" VoIP program like Skype that has an option to allow the program to adjust the audio device levels. But my problem is that all my VoIP apps use WebRTC, which appears to include its own implementation of AGC as part of the protocol, and it's obviously buggy in anything based on Chromium (Chrome, electron apps, etc.), and there's no way to disable it. There have been bug reports to Chrome(ium) for years about this and they obviously don't care. Firefox doesn't exhibit this behavior, but unfortunately a lot of WebRTC apps are either Electron (based on Chromium) or else don't support Firefox very well. Ultimately, I think this behavior should be controllable via PulseAudio, since we can never assume all apps with have sane behavior. In Windows there's an option to not allow programs to control a specific device. I think we also desperately need a PulseAudio option to disable direct access to the audio hardware. It appears this should be possible in `/usr/share/pulseaudio/alsa-mixer/paths/analog-input-internal-mic.conf` by changing `volume = merge` to `volume = off` or `volume = XX` according to what I've read. But since the profiles are under `/usr/share/` they're obviously not meant to be user configurable, which I think should be changed. I'd really appreciate it if you could make this behavior user-configurable, possibly by looking for the profiles somewhere under `/etc/pulse` and/or `~/.config/pulse/`. Thanks a lot! ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
