udev-detect: warn when a sound card is busy

Submitted by Tanu Kaskinen on June 27, 2018, 6:18 p.m.

Details

Message ID 20180627181813.25307-1-tanuk@iki.fi
State New
Headers show
Series "udev-detect: warn when a sound card is busy" ( rev: 1 ) in PulseAudio

Not browsing as part of any series.

Commit Message

Tanu Kaskinen June 27, 2018, 6:18 p.m.
Having a warning in the syslog should make it a bit easier to debug
situations where some other program is hogging the sound card.
---
 src/modules/module-udev-detect.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Patch hide | download patch | download mbox

diff --git a/src/modules/module-udev-detect.c b/src/modules/module-udev-detect.c
index d119f96ae..4598a3d13 100644
--- a/src/modules/module-udev-detect.c
+++ b/src/modules/module-udev-detect.c
@@ -308,7 +308,9 @@  static void verify_access(struct userdata *u, struct device *d) {
              * inotify and can then recheck. */
 
             busy = is_card_busy(path_get_card_id(d->path));
-            pa_log_debug("%s is busy: %s", d->path, pa_yes_no(busy));
+
+            if (busy)
+                pa_log_warn(_("Can't use sound card %s, because some other program is using it."), d->card_name);
 
             if (!busy) {
 

Comments

On Wed, Jun 27, 2018 at 2:19 PM Tanu Kaskinen <tanuk@iki.fi> wrote:

> Having a warning in the syslog should make it a bit easier to debug
> situations where some other program is hogging the sound card.
>

+1. Just the other day someone on IRC had this problem and debug logs were
needed.


> ---
>  src/modules/module-udev-detect.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/modules/module-udev-detect.c
> b/src/modules/module-udev-detect.c
> index d119f96ae..4598a3d13 100644
> --- a/src/modules/module-udev-detect.c
> +++ b/src/modules/module-udev-detect.c
> @@ -308,7 +308,9 @@ static void verify_access(struct userdata *u, struct
> device *d) {
>               * inotify and can then recheck. */
>
>              busy = is_card_busy(path_get_card_id(d->path));
> -            pa_log_debug("%s is busy: %s", d->path, pa_yes_no(busy));
> +
> +            if (busy)
> +                pa_log_warn(_("Can't use sound card %s, because some
> other program is using it."), d->card_name);
>

I think the path info is important because it is something that one can
then pass on to lsof.


>
>              if (!busy) {
>

This should be an else, otherwise it's weird to have if (foo) {} if (!foo)
{} blocks.
On Wed, 2018-06-27 at 15:11 -0400, Felipe Sateler wrote:
> On Wed, Jun 27, 2018 at 2:19 PM Tanu Kaskinen <tanuk@iki.fi> wrote:
> 
> > Having a warning in the syslog should make it a bit easier to debug
> > situations where some other program is hogging the sound card.
> > 
> 
> +1. Just the other day someone on IRC had this problem and debug logs were
> needed.
> 
> 
> > ---
> >  src/modules/module-udev-detect.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/src/modules/module-udev-detect.c
> > b/src/modules/module-udev-detect.c
> > index d119f96ae..4598a3d13 100644
> > --- a/src/modules/module-udev-detect.c
> > +++ b/src/modules/module-udev-detect.c
> > @@ -308,7 +308,9 @@ static void verify_access(struct userdata *u, struct
> > device *d) {
> >               * inotify and can then recheck. */
> > 
> >              busy = is_card_busy(path_get_card_id(d->path));
> > -            pa_log_debug("%s is busy: %s", d->path, pa_yes_no(busy));
> > +
> > +            if (busy)
> > +                pa_log_warn(_("Can't use sound card %s, because some
> > other program is using it."), d->card_name);
> > 
> 
> I think the path info is important because it is something that one can
> then pass on to lsof.

Do you mean that the path is important because it contains the alsa
card index, which can be used to construct an lsof command? The path
itself can't be used:

    $ lsof /devices/pci0000:00/0000:00:1b.0/sound/card0
    lsof: status error on /devices/pci0000:00/0000:00:1b.0/sound/card0: No such file or directory

When adding a /sys prefix:

    $ lsof /sys/devices/pci0000\:00/0000\:00\:1b.0/sound/card0

That provided no output, while aplay is using the device.

    $ lsof /dev/snd/pcmC0*
    COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF  NODE NAME
    aplay   25229 tanu  mem    CHR  116,4          11903 /dev/snd/pcmC0D0p
    aplay   25229 tanu    4u   CHR  116,4      0t0 11903 /dev/snd/pcmC0D0p

I'll add the card index to the log message. Maybe I should also add a
suggestion to use "lsof /dev/snd/pcmCN*" to find out the culprit? But
then the user gets angry and asks "why can't you run lsof yourself?"
which is a valid question, because when the user sees the log message
the situation may have changed already, so it would be best to run lsof
immediately when we notice that the sound card is busy. But then this
trivial patch turns into a project of figuring out how to run lsof and
capture its output from C code...