Bug 327701 - /sbin/salsa needs arguments.... ?
/sbin/salsa needs arguments.... ?
Product: Fedora
Classification: Fedora
Component: alsa-utils (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Martin Stransky
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-10-11 10:13 EDT by Tom London
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-15 10:18:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tom London 2007-10-11 10:13:22 EDT
Description of problem:
/etc/udev/rules.d/90-alsa.rules looks like:
SUBSYSTEM=="sound", KERNEL=="controlC*" RUN+="/sbin/salsa"
SUBSYSTEM=="sound", KERNEL=="pcm*"      RUN+="/sbin/salsa"

I believe running "salsa" without arguments does not restore the settings.

Wouldn't something like:
SUBSYSTEM=="sound", KERNEL=="controlC*" RUN+="/sbin/salsa -l %n"
SUBSYSTEM=="sound", KERNEL=="pcm*"      RUN+="/sbin/salsa"

be better?

[With the controls messed up, running 'salsa' from root console seems to do
nothing.  Running 'salsa -l 0' does in fact restore the settings.]

Is the second line ("pcm*") needed?

Version-Release number of selected component (if applicable):

How reproducible:
every time

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Martin Stransky 2007-10-15 09:03:52 EDT
/sbin/salsa w/o argument is specially designed for this purpose. It loads the
card number from ENV (it's set by udev) and loads stored volume from disc.
Comment 2 Martin Stransky 2007-10-15 09:16:48 EDT
If the volume loading doesn't work for you it could be a dupe of Bug 247468.
Comment 3 Tom London 2007-10-15 10:18:11 EDT
Nah, working now.  [Sorry, filed this after running 'salsa' from terminal
without udev's env variables...]

I think this was and issue with SELinux blocking alsa_t access to
/etc/alsa/asound.state, etc.


Thanks for looking into this.

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