Userspace power manager needs to know about the audio device state

[cjb]

Specifically:

• is the audio device open?
• when (in epoch time, let's say) was the last time it was opened?

We need to avoid suspending in the "device is open" case and the "device was open case", for two different reasons:

1. Suspending while audio is active often breaks audio on resume. This is #4247 and #6201.
2. OHM currently doesn't avoid suspending when Record, Distance, eToys or the Totem plugin are busy with audio, because it doesn't know when those activities are currently using the mic/speakers. Distance, for example, opens the audio device briefly in its "continuous measurement" mode, but is idle when not doing that. The "when was the device last opened" will allow OHM to inhibit suspend for it.

A sysfs interface to the two variables would be perfect.

[AlbertCahalan]

1. stat(your_audio_device, &sbuf)

2. check sbuf.st_atime

[cjb]

Hi Albert,

stat(your_audio_device, &sbuf)

That's the first thing I tried, and /dev/snd/pcmC0D0{p,c} weren't updating their atimes when the device was open or used. Could you confirm whether you see the same thing?

It's not clear that recording the last time the device was opened via atime, if it did that, would be good enough -- if someone's been listening to music for the last ten minutes, I need to know both that it was last opened ten minutes ago, and that it is currently open.

[dilinger]

meh.

[dilinger]

(in case it's not obvious, that patch is incomplete)

[dsaxena]

Replying to cjb:

Specifically: * is the audio device open? * when (in epoch time, let's say) was the last time it was opened? We need to avoid suspending in the "device is open" case and the "device was open case", for two different reasons: 1. Suspending while audio is active often breaks audio on resume. This is #4247 and #6201. 2. OHM currently doesn't avoid suspending when Record, Distance, eToys or the Totem plugin are busy with audio, because it doesn't know when those activities are currently using the mic/speakers. Distance, for example, opens the audio device briefly in its "continuous measurement" mode, but is idle when not doing that. The "when was the device last opened" will allow OHM to inhibit suspend for it. A sysfs interface to the two variables would be perfect.

That sounds really ugly and like it could get out of control (needing sysfs for every device we want to keep track of). And it surely will not ever get accepted upstream.

Can we just use inotify here? Just check for IN_ACCESS, IN_CLOSE_WRITE, and IN_CLOSE_NOWRITE events.

[cjb]

Can we just use inotify here?

That's a good idea, I'll give it a try.

[pgf]

inotify is close, but not quite good enough. turns out data is most often transferred to the device via ioctl(), and inotify won't track that.

it turns out that alsa does offer /proc/asound/card0/pcm0?/sub0/status , which contains a string that corresponds to the device state. in particular "RUNNING" or "DRAINING" tell you that data is being played.

powerd now uses this, but it exposes issues in activities. some activities (Scratch) send data to the device continuously, long after noise is not being made. this is probably a squeak issue. others (notably the TamTam family, Etoys) send data to the device the entire time they're up, whether making noise or not, unless they lose window focus.

[sascha_silbe]

As Paul pointed out correctly on the mailing list (or maybe IRC), simply reading the current status of the audio device is just a point-in-time check. inotify doesn't notice changes to the status file either. So in theory we're opening ourselves up for a race condition. However, it would be a problem even with a better check: AFAICT using the audio device doesn't increment wakeup_count, so if an Activity started using the audio device right before we suspend, we'd have the same problem.

In practice, it will probably be less of a problem, as most usage of audio devices is going to be the direct result of some external event (user input or network traffic).

[pgf]

inhibit of suspend during audio use has been packaged in powerd-103.

peter -- i've packaged and built for x86 -- please do your ARM magic and add to the next build. thanks!

[dsd]

Now in updates-testing for next build.

[pbrobinson]

Already built for ARM and will be in the next updates-testing and hence build.

[pbrobinson]

powerd-103 is in os13

[greenfeld]

Tracing powerd shows "audio busy" messages when the sample audio files included in the libraries are played or the Measure activity is used in 12.1.0 os18.