[Solved] how to detect audio playback using only alsa, without pulseaudio

[GNUser]

With pulseaudio, I can use this trick to figure out if my machine is producing sound:

Code: [Select]

$ grep RUNNING /proc/asound/card*/pcm*/sub*/status
For example, with pulseaudio, I get this when a video or sound file is playing in mpv:

Code: [Select]

$ grep RUNNING /proc/asound/card*/pcm*/sub*/status
/proc/asound/card0/pcm0p/sub0/status:state: RUNNING
$
If I pause the playback in mpv, I get this (as expected):

Code: [Select]

$ grep RUNNING /proc/asound/card*/pcm*/sub*/status
$

The trick doesn't work if I ditch pulseaudio and use apulse instead: Whether mpv is playing or paused, I get this same output:

Code: [Select]

$ grep RUNNING /proc/asound/card*/pcm*/sub*/status
/proc/asound/card0/pcm0p/sub0/status:state: RUNNING
$
So with apulse, if an mpv window exists, card0's state is "RUNNING" even if playback is paused.

So my question is this: Is there a different way to detect whether the soundcard is producing sound, a way that would give me the right answer even in the setting of apulse + paused mpv?

[GNUser]

I found this alternative:

Code: [Select]

$ fuser /dev/snd/timerThe command is supposed to succeed only if sound is playing but, unfortunately, it also succeeds when mpv is paused.

I have a hard time believing that there's no reliable/low-level way to determine whether sound card is producing sound.

P.S. I don't like the title of my thread. A better title would be "how to detect audio playback using only alsa, without pulseaudio".

[Rich]

Hi GNUser

... A better title would be "how to detect audio playback using only alsa, without pulseaudio".

Done.

[curaga]

If your card offers loopback (reading its output as an input), you could write a program to read a few samples, and if their volume is under a threshold, presume silence? Just an idea, otherwise you should ask on the alsa ML.

[GNUser]

Rich,
Thanks for changing the thread title

curaga,
It seems the strategy would be to configure my machine to output audio simultaneously to both ALSA loopback and normal sound device (speakers/audio jack), then write a script that every few seconds records an audio sample from loopback and tests if the sample volume is below a certain low threshold. If so, presume silence.

The ALSA solution seems more complex than dealing with pulseaudio's shenanigans. Since my ultimate goal is to keep things as simple as possible, in this case it seems that loading pulseaudio is the way to go.

[jazzbiker]

Hi, GNUser!

In my system /proc/asound/card0/pcm0p/sub0/status file shows the status of playback.

[GNUser]

Just a quick follow-up about the observations in the initial post in this thread: ALSA was innocent. MPV is the culprit.

I recompiled mpv using the "--disable-pulse" flag. Then I rebooted my TCL box, making sure to load neither pulseaudio nor apulse. Only alsa was loaded.

I then did some tests using Brave (a web browser which, similar to chromium, does not use pulseaudio) and my recompiled mpv:

Results with Brave
When playing audio in the browser, "cat /proc/asound/card*/pcm*/sub*/status" shows "state: RUNNING". If I pause the audio in the browser, after about 5-10 seconds Brave releases the audio card because "cat /proc/asound/card*/pcm*/sub*/status" just shows "closed".

Results with MPV
When playing audio file in my recompiled mpv, "cat /proc/asound/card*/pcm*/sub*/status" shows "state: RUNNING". If I pause the audio, no matter how long I wait "cat /proc/asound/card*/pcm*/sub*/status" continues to show "state: RUNNING". So it seems that unless pulseaudio is being used, mpv does not know how to release the sound card when playback is paused.

    [EDIT]: Changed  --without-pulse  to  --disable-pulse.  Rich

[jazzbiker]

But there are numbers too. hw_ptr and appl_ptr. Does their behaviour changes while paused and running?

[GNUser]

Whether playback is paused or running, those numbers are constantly changing (seemingly randomly).

[jazzbiker]

Hmm, it means mpv continues sending zero samples... I use mplayer, in case playback is paused, it sends nothing, while keeping device owned. Seems curaga's proposal is the only possible way.

[Rich]

Hi GNUser
I did a little experimenting and found:

Code: [Select]

/proc/asound/card0/pcm0p/sub0/infoand

Code: [Select]

/proc/asound/card0/pcm0p/infoshowed changes when playing/pausing YouTube videos.

The following lines showed this when playing:

Code: [Select]

subdevices_count: 1
subdevices_avail: 0and this when paused:

Code: [Select]

subdevices_count: 1
subdevices_avail: 1

[GNUser]

Thanks for the tip, Rich. On my TCL11 x86_64 system, I loaded alsa only (no pulseaudio or apulse). Then I did some tests with mpv (compiled with  --disable-pulse  flag). When I cat the two info files you pointed out, I get this output whether mpv is playing or paused:

Code: [Select]

subdevices_count: 1
subdevices_avail: 0
So I'm still stuck. So far, I cannot find a way for a shell script to distinguish between "mpv playing" and "mpv paused" using only alsa.

P.S. In reply #6, "--without-pulse" is a mistake. I meant "--disable-pulse".

[Rich]

Hi GNUser

... P.S. In reply #6, "--without-pulse" is a mistake. I meant "--disable-pulse".

Fixed.

[jazzbiker]

Hi, GNUser!

The matter is mpv behavior. What are mpv benefits over mplayer?
Another option is curaga's proposal - create additional alsa  device, duplicating Your sound, make short record of its output and check whether it is exceeding some limit. If this is acceptable, i can try to write .asoundrc for Your needs, I think it is not complicated, but I never wrote alsa configs.

[GNUser]

Rich,

mpv is what I use in my family media player. It has a pseudoGUI, which makes it easier for the wife and kids to use.

I submitted a bug report for mpv here: https://github.com/mpv-player/mpv/issues/8691

It's generous of you to offer to write the alsa config that sends output to both loopback and normal device. There is some guidance here (https://github.com/karlstav/cava#alsa-loopback-device-tricky) but I was too intimidated to try it. I'd be very happy to try what you put together. It would be rewarding to solve this using curaga's approach.