Re: [emms-help] mpv player alternative with json-ipc

[Mike Kazantsev]

On Sun, 22 Apr 2018 14:44:30 +0530
Pierre Neidhardt <address@hidden> wrote:

> I've noticed another issue: with mpv constantly running, it keeps
> pulseaudio always up and seems to prevent power management on the audio
> card.
> 
> I'm not sure about the details but a consequence of switching to Mike's
> implementation of the mpv backed has resulted in a 25% drop in battery
> life.

Pretty sure drain is purely due to hardware not being suspended, not
pulseaudio using CPU when idle or anything like that, though you can
check the latter via "top" or similar tools.

Pulse shouldn't exit with --exit-idle-time while there are clients,
which long-running mpv instance is, as well as any volume applets and
such.


Don't think clients or even paused streams should normally prevent
hw/sink from being suspended though.

I'd suggest checking following:


- "pactl list modules | grep module-suspend-on-idle" - should be there.

  More info on the module:
  
https://wiki.freedesktop.org/www/Software/PulseAudio/Documentation/User/Modules/#index64h3

  Should be loaded in default configuration.


- "pactl list sinks" and check "State: ..." line there.

  For me it changes like this:

  - RUNNING when mpv playback is active and I can hear sounds.

  - IDLE immediately after playback in mpv is paused or stopped, with
    mpv process still running.

  - SUSPENDED after 5 seconds from pausing/stopping mpv playback.

  This should be due to module-suspend-on-idle default timeout= value
  (5s).


- Check if pulseaudio suspends ALSA device - in pulseaudio logs.

  E.g. stop the thing if it's running, and start in verbose mode:

    % systemctl --user stop stop pulseaudio.socket pulseaudio
    % pulseaudio --daemonize=no\
        --disallow-exit --exit-idle-time=99999999 -vvvvv -n 2>&1 |
      tee > pa.log

  And check for output like this there:

    I: [pulseaudio] module-suspend-on-idle.c: Source 
alsa_input.pci-0000_00_14.2.analog-stereo idle for too long, suspending ...
    D: [pulseaudio] source.c: Suspend cause of source 
alsa_input.pci-0000_00_14.2.analog-stereo is 0x0004, suspending
    I: [alsa-source-Generic Analog] alsa-source.c: Device suspended...
    ...
    D: [pulseaudio] module-suspend-on-idle.c: Sink 
alsa_output.pci-0000_00_14.2.analog-stereo becomes busy, resuming.
    D: [pulseaudio] sink.c: Suspend cause of sink 
alsa_output.pci-0000_00_14.2.analog-stereo is 0x0000, resuming
    D: [pulseaudio] reserve-wrap.c: Successfully acquired reservation lock on 
device 'Audio0'
    I: [alsa-sink-Generic Analog] alsa-sink.c: Trying resume...


- If you can hear when audio hardware is suspended vs active (e.g. pop
  then silence instead of low background hum), then I'd suggest also
  making sure that it follows what pulseaudio does, in case it's
  failing to do so despite the log output.

  Alternatively, check output of something like this:

    # lsof -p $(pgrep -x pulseaudio) | grep /dev/snd/pcm

  It should have stuff like "/dev/snd/pcmC0D0p" listed in there when
  sink is RUNNING, but close them completely when SUSPENDED, thus
  cutting off any possible use of actual hardware, allowing it to be
  suspended by kernel.


- If all these work fine, and audio hw indeed seem to be suspended by
  pulse, but you still get power drain, I'd suggest checking powertop
  or such, once with pulseaudio process killed (make sure it's not
  auto-started), and once with it running.

  And see if it can point to specific process or kernel routine
  doing something weird with pulse running, might be a bug somewhere,
  I think.


> I'm not saying that this is necessarily emms-player-mpv.el's fault: it
> could be an issue with power management on my end.  Pulseaudio should be
> able to sleep when no track is playing I guess.  The issue could be with
> mpv itself.

Don't think mpv does anything special - just runs a persistent pulse
client, same as e.g. volume applet in whatever desktop environment
would do, and that shouldn't cause an issue.

When it's playing or paused, it also has a stream running, but that
should be nothing new, as it does that without --idle as well.

And indeed, pulseaudio should suspend sink and underlying hardware by
default if there are no actual audio samples going through there,
regardless of whether there are clients or streams created in it.


It is possible to do what module-suspend-on-idle does in pulse with mpv
process though, i.e. setup run-at-time timer on emms-player-stopped-hook
to check emms-player-playing-p or run emms-mpv-proc-stop there.

Doing that by default would break some of those nice use-cases for
long-running mpv though.

Knowing what's the exact issue in your case might open a possibility to
check and workaround for it, at least if it looks common enough, so
would be cool if you could find the cause of that thing.


-- 
Mike Kazantsev // fraggod.net