where does pulseaudio store session information?

Lennart Poettering mzerqung at 0pointer.de
Mon Sep 22 20:37:00 UTC 2008


On Mon, 22.09.08 11:46, Tomasz Torcz (tomek at crocom.com.pl) wrote:

> 
> Dnia 2008-09-22, pon o godzinie 11:32 +0200, Christoph Höger pisze:
> > Hi,
> > 
> > I encounter the following behaviour: When I mute my notebook, after a
> > reboot the sound is enabled at full volume level. That's annoying.
> > I figured out that pulseaudio runs a rather small app named
> > gconf-helper. The source code indicates that this app gets some gconf
> > values from /system/pulseaudio/ but that key seems not to exist.
> 
> > So where (if at all) does pulseaudio store its data?
> 
>   in ~/.pulse/volume-restore-table. But aren't volume levels supposed to
> be stored in /etc/asound.state by "alsactl store" invoked by init
> scripts on shutdown? And restored on boot
> by /etc/udev/rules.d/90-alsa.rules ?

Please note that on Rawhide PA actually stores the stream volume tables in
~/.pulse/<dbus machine id>:stream-volumes.<build arch>.gdbm.

We include the D-Bus machine id in the name because of NFS
safety. The build arch is included in the name because gdbm files are
arch-dependant.

PA from rawhide always saves/restores device volumes in ~/.pulse/<dbus
machine id>:device-volumes.<build arch>.gdbm. We don't rely on alsactl
store for (at least) three reasons:

1) I believe that volume information should be a user and not a system
setting.

2) When an ALSA audio device is unplugged it is already too late to
save its volume if we just use alsactl. Since PA is running
continouisly and caches the volume setting we can save the volume when
it changes.

3) Many audio devices support only very limited volume control: the
minimal volume is not actually silence, no seperate per-channel
volumes are supported, only very few levels are supported. PA will
always extend the hardware volume range in software and thus exposes
the same volume capabilities on all hardware, even the most limited
one. However, since PA's volume settings are thus not necessarily in
the range the hardware supports and we thus cannot rely on "alsactl
store" doing the job for us.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4




More information about the fedora-devel-list mailing list