Ticket #6670 (closed defect: fixed)

Opened 6 years ago

Last modified 22 months ago

Userspace power manager needs to know about the audio device state

Reported by: cjb Owned by: pgf
Priority: high Milestone: 12.1.0
Component: kernel Version: Development source as of this date
Keywords: Cc: sascha_silbe, pbrobinson
Action Needed: no action Verified: no
Deployments affected: Blocked By:
Blocking:

Description

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.

Attachments

6670_alsa_braindamage.patch (3.0 kB) - added by dilinger 6 years ago.
meh.

Change History

  Changed 6 years ago by AlbertCahalan

1. stat(your_audio_device, &sbuf)

2. check sbuf.st_atime

  Changed 6 years ago by cjb

  • cc AlbertCahalan added

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.

Changed 6 years ago by dilinger

meh.

  Changed 6 years ago by dilinger

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

  Changed 6 years ago by dsaxena

  • cc dsaxena added

in reply to: ↑ description   Changed 6 years ago by 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.

  Changed 6 years ago by cjb

Can we just use inotify here?

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

  Changed 6 years ago by dsaxena

  • cc dilinger added
  • owner changed from dilinger to cjb
  • next_action set to never set

  Changed 2 years ago by pgf

  • cc sascha_silbe added; AlbertCahalan, dsaxena, dilinger removed
  • owner changed from cjb to pgf
  • summary changed from Userspace (OHM) needs to know about the audio device state to Userspace power manager needs to know about the audio device state

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.

  Changed 2 years ago by pgf

  • priority changed from blocker to high
  • version set to Development source as of this date
  • milestone changed from 8.2.0 (was Update.2) to 12.1.0

  Changed 2 years ago by 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).

  Changed 2 years ago by pgf

  • cc pbrobinson added
  • next_action changed from never set to add to release

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!

  Changed 23 months ago by dsd

  • next_action changed from add to release to add to build

Now in updates-testing for next build.

  Changed 23 months ago by pbrobinson

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

  Changed 23 months ago by pbrobinson

  • next_action changed from add to build to test in build

powerd-103 is in os13

  Changed 22 months ago by greenfeld

  • status changed from new to closed
  • next_action changed from test in build to no action
  • resolution set to fixed

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.

Note: See TracTickets for help on using tickets.