[Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830

[Sascha Silbe]

[CC'ing devel at l.l.o because it touches operation of low-level software
components on OLPC OS]

Paul Fox <pgf at laptop.org> writes:

> the problem is that there's no good operating system mechanism that
> powerd can use to know that audio is truly in use.
>
> it's possible to know that the audio device has been opened, and i
> have tried using that in the past.  but most applications that use
> audio open the device once, and then leave it open.  so even when
> they're playing nothing but silence, the device appears to be in use.

While there could (and maybe should) be a distinction between the audio
device being a) opened by a process and b) in actual use for playback or
recording, ALSA doesn't make that distinction [1] and a lot of
commonplace hardware doesn't support more than one substream. As long as
the device is open, no other process will be able to use the
device. Whether we like it or not, this is the kernel-level ALSA API and
if applications don't obey their side of the contract (closing the
device to de-allocate resources) it's simply an application bug.

I haven't dug into GStreamer enough to tell what its API looks like
w.r.t. resource acquisition and how that translates into ALSA device
usage, but powerd is only concerned about the kernel level and a number
of well-behaving Activities show that there's no major roadblock ahead;
in fact a close look at the Record source doesn't even reveal any
obvious kind of hack.


> regarding the other elements of this thread:  it may be that system
> mechanisms for inhibiting suspend via upowerd or gnome are now mature
> enough to be of some use.  this has never seemed to be the case in the
> past.  plus -- they're all, as far as i can tell, just as specific to the
> power-manager-du-jour as the current powerd interfaces are.  i.e., no
> one has created a generic set of interfaces which can be implemented
> in various ways behind the scenes.

Yes, many of the Gnome APIs (remember, Sugar is built on Gnome
components) are annoyingly specific to Gnome components. There are a
number of cross-desktop environment APIs being worked on at
freedesktop.org [2], but nothing related to session or power management
is among them. The inhibit support of XSMP [3] is claimed [4] to be
problematic, so no common base there either.

When it comes to power management, we're living in a constantly changing
world. Like with any standardisation effort, it will take a) someone to
drive it and b) considerable time and effort to design and get people to
agree on a common API.

I've tried looking at what the APIs KDE uses for power management, but
only hit a number of partially [5,6] or completely [7-9] broken API docs
pages. What I've seen so far doesn't like any better or more
cross-desktop environment than what Gnome does.

Sascha

[1] http://www.alsa-project.org/~tiwai/writing-an-alsa-driver.pdf
    page 28 (page 21 using in-pdf numbering)
[2] http://www.freedesktop.org/wiki/Specifications
[3] http://www.x.org/releases/X11R7.6/doc/libSM/xsmp.html
[4] http://live.gnome.org/SessionManagement/GnomeSession#Problems_and_Goals
[5] http://www.purinchu.net/kdelibs-apidocs/solid/html/namespaceSolid_1_1PowerManagement.html
[6] http://www.purinchu.net/kdelibs-apidocs/solid/html/powermanagement_8cpp_source.html
[7] http://api.kde.org/
[8] http://api.kde.org/4.x-api/kdelibs-apidocs/
[9] http://api.kde.org/4.8-api/kdelibs-apidocs/
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20120521/706ceea6/attachment.pgp>