Mpv: PulseAudio automute

[treaki]

hi,

normally if i enter mpv its starts with enabled audio. But there are situations that happen in correlation with voip software (mumble, teamspeak, sip softphones) where mpv mutes itself. i can press the m key on my keyboard to unmute mpv again but it get muted again after some conditions. Also if i am playing some more files it happens much often that after one file ends and another starts it is muted again. it can be very annoying if you are listening to an music album and you have to unmute mpv every song.

On the one hand its a nice feature that if i cant an incoming voip call mpv mutes itself automaticly... But pause in this situation would be much better and i wouldnt have to seek back to find the video position at beginning of the call.

I was unable to find more information about this feature. So here are some questions about:

• how to disable it completely? is there something like --noautomute ?
• How ecactly dose it work. Is there a inter process communication interface using dbus or pulseaudio? where can i find more information about?
• Is it possible to enable this feature only for certain application (for example enable automute at incoming voip calls but disable it for teamspeak)

thanks for the help, here are some systeminfos:

treaki@treakis-tp:~$ lsb_release -a
LSB Version:    security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
Distributor ID: Debian
Description:    Debian GNU/Linux testing (jessie)
Release:    testing
Codename:   jessie
treaki@treakis-tp:~$ uname -a
Linux treakis-tp 3.16-2-amd64 #1 SMP Debian 3.16.3-2 (2014-09-20) x86_64 GNU/Linux
treaki@treakis-tp:~$ mpv -version
mpv 0.6.0 (C) 2000-2014 mpv/MPlayer/mplayer2 projects
 built on Tue Sep 30 20:37:11 UTC 2014
ffmpeg library versions:
   libavutil       54.7.100
   libavcodec      56.1.100
   libavformat     56.4.101
   libswscale      3.0.100
   libavfilter     5.1.100
   libavresample   2.1.0

treaki@treakis-tp:~$ 

[ghost]

PulseAudio does this. PulseAudio tries to be clever, but as usual when software tries to be clever, it leads to strange behavior no user can comprehend. At least I think that's what's happening in this case. I don't know if there's such a feature in pulse or how to disable it, but I heard similar reports.

If that is the case, mpv has no control over this. It could unmute on start, but normally we prefer not to touch system/user state. I think starting with --mute=no may help.

[ghost]

Oh, and if it turns out that it's actually a mpv issue, I'll gladly fix it given enough information.

[ahodesuka]

You need to disable the cork module in PulseAudio.
To do so comment out load-module module-role-cork in /etc/pulse/default.pa.

[ghost]

And there's no way to programmatically work this around?

I know, you're probably not _supposed_ to work it around, but it continues to cause weird behavior (as perceived by the users).

[ahodesuka]

And there's no way to programmatically work this around?

Reverting #251 would do it, but I think a note in the docs would be a better solution.

[ghost]

I don't even know what #251 does. So is it harmful for a video player to set this video role?

[ahodesuka]

It should set it's role as video - since some may desire this behavior.
It's just silly that PulseAudio has this intrusive module enabled by default.

[treaki]

thanks for your information about that. I guess i should read a little more about this complex topic called pulseaudio... I will try out to disable that module as soon as i get this problem again...

[ghost]

I undid it, because it's too much of a bother at all.

[treaki]

undid what, which what consequences?

[ghost]

See b7325b2. What consequences? I have no idea, maybe not even the pulse devs know. Identifying as video role sets a "policy", which I suppose every user and pulseaudio module can change, so who knows what it actually does.

[morfikov]

I think people don't know how to configure PulseAudio server so they have the mute issue, or any other issues. I've just finished reading 1 and 2 . Unfortunately, I couldn't find any documentation on module-role-cork, but it simply mutes all streams when a stream from the phone class/role is playing. So, this is the default PulseAudio behavior -- you can change it if you don't like it, it's not a bug!

I disabled module-role-cork and enabled module-role-ducking and was able to make a pretty decent setup with TS3 and Amarok that works as expected (I know the two have roles phone and video set, so that's why I used them in the test). When someone is talking on TS3, amarok lowers the volume to 60% (the value can be customized). So where's the problem? Both modules work as expected.

Problem is when an application doesn't have the role set -- then the volume stays the same no matter what. I like both of the features of PulseAudio and I just want to ask if there's a possibility to add the role to mpv so it could work as it should? So far I have the following version built on 2015-05-03T10:56:33, and it simply doesn't work with it.

I've also tested this:
$ PULSE_PROP='media.role=video' mpv movie.mp4
That also works as expected.

[ghost]

So where's the problem?

The problem is that pulse's idiotic defaults get blamed on mpv.

[morfikov]

I 'm just saying that everything is as it should, and works perfectly well, and I think the mpv should have the role of video by default, so I (and others) could use the following settings:

### Cork music/video streams when a phone stream is active
#load-module module-role-cork
load-module module-role-ducking trigger_roles=phone ducking_roles=music,video,game volume=60%

so the voip clients can lower the volume of music, video, and game streams to 60% when needed.

And again, we who read the documentation are punished for that. :]

[Earnestly]

Heh, @wm4 would you mind reverting this? It's a bit annoying have to hack the property back into the environ. Mpv was well behaved and did the Right Thing™, your initial reaction to state it wasn't an mpv bug should have been enough.

[To emphasise, it should not be mpv's job to hack around other software and users who don't understand what's going on.]

[Nowaker]

While I'm an Arch Linux user, and configuring my system isn't anything new to me, I have side with @wm4. Being blamed for PulseAudio's stupid settings isn't anything nice. Hackers like us can hack things, e.g. recompile with video role. "Users who don't understand what's going on" can't so shouldn't be exposed to stupid things like this.

[haasn]

@Earnestly
As a compromise, how about getting the upstream default behavior fixed so we no longer have a motivation to hack around it?

[Earnestly]

@haasn Upstream isn't doing anything wrong though and you were never "hacking around" it (except now you are). They do a few other things wrong though, like autospawn and flat-volumes, in my opinion.

Why pick on PulseAudio? If I press spacebar and it pauses mpv, is that a bug and should be removed, or should I as a charitable user read the damn documentation?

What about the default (correct) state of ALSA to mute all devices initially? Is that an mpv bug if I get no sound?

I could go on, but I cannot honestly see why anyone reasonable would see this as a real bug requiring broken changes to "workaround" it. The initial response that this isn't an mpv problem/bug should have been enough.

_Edit/Rant: What makes this point even worse is that while user friendly distros can easily change this behaviour in their packages, a user centric distro like Arch Linux assumes the user isn't a complete fool and capable of changing the software to suit their needs. So one user didn't bother reading the documentation for pulseaudio on Arch, suddenly mpv should do the wrong thing to appease them?_

_I'm not particularly invested in this, but it does grind me the wrong way to see projects breaking behaviour due to bad users in general._

[ghost]

This is completely unintuitive and surprising behavior, and you can't even know what caused it or what component is at fault. (Users would just blame mpv, because mpv is one of the few things that actually identifies - or did identify - itself as video player to PA.)

If you compare this with hitting spacebar - this is pretty intuitive. Even a user who has never seen a player which pauses before, he'd probably instinctively hit spacebar again and then would understand what it does.

Why PA would make such a weird behavior a default - nobody knows.

By the way, has anyone filed a bug report yet?

(Also, only ALSA is shitty enough to mute everything by default (no other OS would do this). So that's not really a good example.)

[Earnestly]

Muting all sound sources by default is a very sane thing to as it cannot predict what kind of sound output would result. This kind of assumption can even cause physical harm, so no, it's not "shitty" to mute by default.

_(Also, I have to laugh at the "spacebar is intuitive" bit, just how much of an echo chamber do you have to be in to believe this is true? Hell, most of the people I know barely have any intuition for computer systems whatsoever, while the people I know on the internet do. Maybe you think mpv is advanced enough that only somewhat advanced users might use it? In which case, why are you catering to fools by breaking defined behaviour and forcing every competent user to make shell script wrappers around mpv to set up proper environments again?)_

But it's obvious here that because it's PulseAudio this isn't going to be fixed.

Edit: Even after the exact use case was explained clearly (https://github.com/mpv-player/mpv/pull/251) (which suddenly was a surprise to you (@wm4)?) and the original user (which oddly became _"the users"_) admitted to not having read the documentation or even bothered understanding the software he's using, on friggen Debian testing, seriously?

But I'll stop now, this is clearly not bringing the best out of anyone.

[morfikov]

Something can be fixed only when it's broken. This pulse feature isn't a bug. Try to imagine an usual phone call while you're listening to the music. What would be the very first thing you would do when you heard the phone ringing? I think, you would mute the music (or at least lower the volume), and the same idea is behind this pulse feature -- apps have roles assigned and those that can interfere with your voip clients are muted. Look at VLC:

pulseaudio[104122]:     media.role = "video"
pulseaudio[104122]:     application.name = "VLC media player"

Do you see what role it has assigned? And this is just an example, amarok is another one -- they're really popular and they don't have problems with this "bug".

As I said earlier, you can "fix" it if you don't like this kind of behavior. But if you don't want to set the proper role, you can always set something like video-mpv (or whatever), then voip clients won't mute mpv and I can simply add this role to:

load-module module-role-ducking trigger_roles=phone ducking_roles=music,video,video-mpv volume=60%

and everybody will be happy. I tested it with

PULSE_PROP='media.role=video-mpv' mpv

and it works.

[haasn]

The concrete bug here is that, even if the user manually unmutes the stream, it keeps getting re-muted by pulseaudio every time the track switches.

This is clearly undesirable behavior. If the user manually unmuted the mpv stream, pulseaudio should not consistently try to re-mute it.

[ghost]

We probably reload pulse in these events; I'm pretty sure the Pulse perspective would claim that this is our bug. (I don't agree, though.)

[patrakov]

You were apparently relying on the behaviour that PulseAudio didn't cork streams without the role. That was a bug, which is now fixed. There is no reason anymore for you not to set the correct role - users will complain about muting either way. Not my decision, though. See https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=61164d3b5127fe93050f1a66e3d5b67b911560f0

[Earnestly]

Can this please get reverted?

[ghost]

Why?

[haasn]

The concrete bug here is that, even if the user manually unmutes the stream, it keeps getting re-muted by pulseaudio every time the track switches.

Is this not still the case? I may be misunderstanding the issue, but from my perspective this is the only thing that actually needs fixing. In which case, having the pulse state persist across tracks (or something) would be the proper fix to this specific issue.

As far as mpv getting automuted at all, I don't think that's as much of an issue, since the user (i.e. @treaki) clearly seems to understand it (having to do with voip software running), and also that it's a system-wide and upstream policy that would need to be toggled to get rid of this altogether.

If the track-consistency thing is the concrete bug, then applying or reverting this commit over and over again will _not_ affect it. (And more importantly, in the presence of a fix for that, tagging mpv's role as a video player or not will not matter much - _especially_ in light of what @patrakov claimed)

[ovidiu-birgu]

how I removed this annoying "feature" :

#!/bin/bash
#pactl list short | grep -i cork
#pactl list short | grep -i augment
#pactl unload-module xx

pactl list short | grep -i cork  > audioids.txt
pactl list short | grep -i augment  >> audioids.txt

arr=$(cat audioids.txt | grep -oE '^\s*[0-9]+')

for arrval in $arr
do
  #echo $arrval
  pactl unload-module $arrval
done

truncate -s 0 audioids.txt

1) I get the IDs for the cork and augment modules and save them in a file
2) for each ID in the file, unload the module

note: once you execute the script, it is valid until you reboot pc (to solve permanently, put the script in the execute on start-up list)

[j605]

Or you could just write user configuration in ~/.config/pulse/default.pa and unload the module if it has been loaded.