Bug 293301 - Looks like upstream or debian is storing /etc/asound.state under var/lib.
Summary: Looks like upstream or debian is storing /etc/asound.state under var/lib.
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: alsa-utils
Version: rawhide
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Martin Stransky
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-09-17 14:16 UTC by Daniel Walsh
Modified: 2007-11-30 22:12 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-10-01 09:57:12 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Daniel Walsh 2007-09-17 14:16:29 UTC
Description of problem:

It would make SELinux easier to manage if this file or any other statefiles of
alsa were stored under /var/lib/alsa

Stateless would probably work better also.

Comment 1 Martin Stransky 2007-09-17 14:21:55 UTC
I'm fine with that...

Comment 2 Martin Stransky 2007-09-19 12:41:20 UTC
added to alsa-utils-1.0.15-0.1.rc1.fc8

Comment 3 Bill Nottingham 2007-09-25 15:06:07 UTC
/var isn't guaranteed to be mounted when modules are loaded on boot.


Comment 4 Martin Stransky 2007-09-27 13:34:30 UTC
Honestly I don't care where the configuration is stored so it's up to you, guys...

Comment 5 Bill Nottingham 2007-09-27 14:07:47 UTC
Well, if it's stored in /var, any system with a separate /var won't restore
correctly on startup. So I think it has to be in /etc.

Comment 6 Daniel Walsh 2007-09-27 17:57:51 UTC
Why are we restoring sound settings so early in the boot process?  Why is udev
doing this instead of hal?  Hal does not get started until after /var is mounted
correct?

Comment 7 Bill Nottingham 2007-09-27 18:10:15 UTC
Because the simplest, easiest, and most correct point to do it is when the
module is loaded.

Comment 8 David Zeuthen 2007-09-27 18:19:33 UTC
(In reply to comment #7)
> Because the simplest, easiest, and most correct point to do it is when the
> module is loaded.

No, it's both incorrect and inappropriate. Audio volume is a per-user thing and
now that we have pulseaudio in the default install it should set the volume when
your desktop session starts. Then it'll also magically work for
fast-user-switching etc.

When the module loads, it should set a default reasonable volume. IIRC, Lennart
told me that ALSA upstream will do that anyway (Then we can also get away with
sillyness like running alsaunmute on the livecd path etc.).



Comment 9 Bill Nottingham 2007-09-27 18:35:06 UTC
If by 'reasonable volume' you mean 'every channel muted', sure, that's what alsa
usptream does.

Frankly, the fact that you're running alsaunmute in the livecd is broken anyway,
as it should already be unmuted by the aforementioned udev rules which set it to
a reasonable default volume.


Comment 10 David Zeuthen 2007-09-27 18:43:56 UTC
(In reply to comment #9)
> If by 'reasonable volume' you mean 'every channel muted', sure, that's what alsa
> usptream does.

Sorry, I forgot to mention that this is a new feature (on load, setting the card
to a reasonable volume vs. muted); I'm not even sure it's in a release yet.. But
I do recall Lennart mentioning this change from this trip report when meeting
with Takashi Iwai. Either that or a single simple invocation of a future alsactl
version (similar to our in-house alsaunmute) would do it. Lennart?

Either way, saving/restoring volume is something I think we should just leave to
PulseAudio.

Comment 11 Daniel Walsh 2007-09-27 18:49:45 UTC
Sorry, I forgot to mention that this is a new feature (on load, setting the card
to a reasonable volume vs. muted); I'm not even sure it's in a release yet.. But
I do recall Lennart mentioning this change from this trip report when meeting
with Takashi Iwai. Either that or a single simple invocation of a future alsactl
version (similar to our in-house alsaunmute) would do it. Lennart?

Either way, saving/restoring volume is something I think we should just leave to
PulseAudio.



Comment 12 Bill Nottingham 2007-09-27 19:01:40 UTC
All I'm saying is:

1) we have a mechanism to set a sane volume on both boot and card hotplug
2) it uses upstream alsa code and configuration files
3) it has the advantage of using any saved volume that the user or administrator
decided to set using upstream alsa tools and configurations
4) we break it by moving the files from /etc to /var

I really don't care what sort of ALSA vaporcrack is coming down the pipe, and
what GNOME wants to do with PA on top of this will work fine too. It's orthogonal.


Comment 13 Daniel Walsh 2007-09-27 19:09:22 UTC
So I have no problem going back to /etc.  Don't know if this is a notabug or do
you want to keep it open to remember to change it back to previous version.

Comment 14 Lennart Poettering 2007-09-29 21:42:00 UTC
Sometime after F8 I plan to add audio device restoring to PA in a away that is
also compatible with fast users switching and suchlike.

Takashi promised to add a new switch to alsactl which can be used to reset the
sound card volume to something "sensible" in terms of what actually makes sense
on the hw, i.e. some value that is roughly the same signal level on all sound cards.

Comment 15 Martin Stransky 2007-10-01 08:15:02 UTC
(In reply to comment #8)
> When the module loads, it should set a default reasonable volume. IIRC, Lennart
> told me that ALSA upstream will do that anyway (Then we can also get away with
> sillyness like running alsaunmute on the livecd path etc.).

If so they have to fix each single driver (the best variant) or use something
similar to alsaunmute (the worse one).

Anyway, we should have some way how to set-up default ALSA volume w/o PA.

Comment 16 Martin Stransky 2007-10-01 09:57:12 UTC
configuration moved back to /etc/alsa/asound.state. package alsa-utils
1.0.15-0.4.rc1.

Comment 17 Lennart Poettering 2007-10-01 17:05:37 UTC
(In reply to comment #15)
> (In reply to comment #8)
> > When the module loads, it should set a default reasonable volume. IIRC, Lennart
> > told me that ALSA upstream will do that anyway (Then we can also get away with
> > sillyness like running alsaunmute on the livecd path etc.).
> 
> If so they have to fix each single driver (the best variant) or use something
> similar to alsaunmute (the worse one).

Takashi wants to go the second way.


Note You need to log in before you can comment on or make changes to this bug.