Bug 247468 - nas should not modify sound card volume on start
nas should not modify sound card volume on start
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: nas (Show other bugs)
7
All Linux
low Severity medium
: ---
: ---
Assigned To: Frank Büttner
Fedora Extras Quality Assurance
:
: 243635 249804 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-09 10:55 EDT by Valent Turkovic
Modified: 2007-11-30 17:12 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-02 13:31:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
here is my /root/scsconfig.log (75.83 KB, text/plain)
2007-07-09 13:42 EDT, Valent Turkovic
no flags Details
My SCSConfig.log file (48.73 KB, text/plain)
2007-07-09 16:04 EDT, Rogue
no flags Details
scsconfig.log of my system (61.53 KB, text/plain)
2007-07-09 17:43 EDT, Vivek J. Patankar
no flags Details
asound.state (3.07 KB, text/plain)
2007-09-19 14:24 EDT, Valent Turkovic
no flags Details
amixer (1.82 KB, text/plain)
2007-09-19 14:25 EDT, Valent Turkovic
no flags Details
asound.state (7.43 KB, application/octet-stream)
2007-09-19 17:59 EDT, Chris
no flags Details
Chkconfig --list out put (7.26 KB, text/plain)
2007-10-08 00:01 EDT, Gian Paolo Mureddu
no flags Details
patch for this issue (754 bytes, patch)
2007-11-02 11:32 EDT, Bill Nottingham
no flags Details | Diff

  None (edit)
Description Valent Turkovic 2007-07-09 10:55:27 EDT
Description of problem:
gnome-volume-control doesn't remember setings for PCM channel on reboot
I set volume to 80% to both master and PCM channel, on reboot I expect them to
be as I set them - but PCM channel repeatedly gets down to 50%


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


How reproducible:
every time

Steps to Reproduce:
1. set volume of PCM and master channel to 80%
2. reboot the system
3.
  
Actual results:
PCM channel repeatedly gets down to 50% instead of staying at desired value
before reboot.

Expected results:
PCM and master channels staying at chosen volume level.

Additional info:
Comment 1 Bastien Nocera 2007-07-09 10:58:55 EDT
This is supposed to be done by the alsactl call in the halt initscript. As I
don't think the initscript itself is the problem, I'd gather it's with alsactl.
Comment 2 Martin Stransky 2007-07-09 11:14:51 EDT
Can you please attach /root/scsconfig.log? (it can be generated by
system-config-soundcard). What sound device(s) is affected with this issue?
Comment 3 Antonio A. Olivares 2007-07-09 12:59:11 EDT
Mr. Stansky,

I guess that all devices are affected by this issue.  Why have not more people 
complained is that they have found a workaround.  Instead of complaining, they 
saved the sound settings to their liking by becoming superuser 
$ su -
password 
and typing
# alsactl store 
and adding the line /usr/sbin/alsactl restore to the file
/etc/rc.local 
file.  This is the workaround that fixes this issue.  With respect to the 
initscripts, where is it that the /usr/sbin/alsactl restore gets called?

Thanks,

Antonio 
Comment 4 Valent Turkovic 2007-07-09 13:42:26 EDT
Created attachment 158792 [details]
here is my /root/scsconfig.log

here is my /root/scsconfig.log
Comment 5 Valent Turkovic 2007-07-09 14:03:24 EDT
This should be posted as a bug no matter if the workaround exists or not.
Comment 6 Rogue 2007-07-09 16:04:59 EDT
Created attachment 158800 [details]
My SCSConfig.log file

I too see this error, so attaching my log file too.
Comment 7 Vivek J. Patankar 2007-07-09 17:43:02 EDT
Created attachment 158808 [details]
scsconfig.log of my system

I have also noticed that the defaulted settings for each user is different. My
main user (uid 500) has the default PCM set at 51%. For the "guest" (UID 501)
user the setting is at 74%.

Also, here's my system profile
http://smolt.fedoraproject.org/show?UUID=1d344b4d-6329-4ae5-aa26-0b9e72a12d77
Comment 8 Valent Turkovic 2007-07-12 08:00:38 EDT
do you need some more feedback for this bug from me?
Comment 9 Martin Stransky 2007-07-12 08:07:50 EDT
no, thanks for the report.
Comment 10 Vivek J. Patankar 2007-08-01 17:31:36 EDT
   IMHO, there is nothing wrong with alsactl or salsa. Both do the job perfectly
well.
   This bug should have been filed against the 'initscripts' package.
   /etc/init.d/halt calls /sbin/salsa to save the current configuration. But it
is not called at startup by any script in /etc/init.d/ or /etc/rc.d/init.d/ to
reload the configuration during boot.

   Also, why have a new thing called salsa that does it differently when
'alsactl store' did the job perfectly well to begin with. Jurgen mentioned in
the users list that FC6 called alsactl, which means this new utility was added
in FC7.
Comment 11 Antonio A. Olivares 2007-08-02 12:33:32 EDT
Daer all,

Vivek is correct in what he has stated.  The halt procedure calls salsa to save
the settings, but there is no corresponding init script that calls salsa -l to
load it at startup.

In halt procedure there is  

# Save mixer settings, here for lack of a better place.
grep -q "\(alsa\)" /proc/devices
if [ $? = 0 -a -x /sbin/salsa ]; then
   action $"Saving mixer settings" /sbin/salsa -s
fi

When starting up there is something called Network Audio deamon or soemthing
like that /etc/rc.d/init.d/nasd.  Is it the one that should have the command
/sbin/salsa -l 

[root@localhost ~]# cat /etc/rc.d/init.d/nasd 
#!/bin/bash
#
# nasd        Starts nasd.
#
#
# chkconfig: 345 88 88
# description: Network transparent audio server

#Servicename
SERVICE=nasd
....,  

Is this the file that should have "/sbin/salsa -l" or not?  
Where can we put the following

# Load mixer settings, where for the lack of a place in initscripts?
grep -q "\(alsa\)" /proc/devices
if [ $? = 0 -a -x /sbin/salsa ]; then
   action $"Loading mixer settings" /sbin/salsa -l 
fi

in here --> /etc/rc.d/init.d/nasd

or where?

Where should it be?  
Comment 12 Antonio A. Olivares 2007-08-02 13:27:07 EDT
Daer all,

Vivek is correct in what he has stated.  The halt procedure calls salsa to save
the settings, but there is no corresponding init script that calls salsa -l to
load it at startup.

In halt procedure there is  

# Save mixer settings, here for lack of a better place.
grep -q "\(alsa\)" /proc/devices
if [ $? = 0 -a -x /sbin/salsa ]; then
   action $"Saving mixer settings" /sbin/salsa -s
fi

When starting up there is something called Network Audio deamon or soemthing
like that /etc/rc.d/init.d/nasd.  Is it the one that should have the command
/sbin/salsa -l 

[root@localhost ~]# cat /etc/rc.d/init.d/nasd 
#!/bin/bash
#
# nasd        Starts nasd.
#
#
# chkconfig: 345 88 88
# description: Network transparent audio server

#Servicename
SERVICE=nasd
....,  

Is this the file that should have "/sbin/salsa -l" or not?  
Where can we put the following

# Load mixer settings, where for the lack of a place in initscripts?
grep -q "\(alsa\)" /proc/devices
if [ $? = 0 -a -x /sbin/salsa ]; then
   action $"Loading mixer settings" /sbin/salsa -l 
fi

in here --> /etc/rc.d/init.d/nasd

or where?

Where should it be?  
Comment 13 Antonio A. Olivares 2007-08-02 13:31:23 EDT
Air Collision or something like that happened.  Sorry for posting double.  Will
ask on fedora-list/fedora-test-list which init script should be loading sound
settings. 

Thanks,

Antonio 
Comment 14 Vivek J. Patankar 2007-08-03 00:01:20 EDT
Can we close this bug and file a new bud against the initscripts package?
Martin, this bug is assigned to you. Your call.
Comment 15 Martin Stransky 2007-08-03 03:51:06 EDT
Moved to initscripts. Thanks for your time and effort, guys.
Comment 16 Bill Nottingham 2007-08-03 09:57:39 EDT
The volume settings should be automatically restored by udev when the module is
loaded; it is not an initscripts issue.
Comment 17 Harald Hoyer 2007-08-03 11:35:26 EDT
$ rpm -qf /etc/udev/rules.d/90-alsa.rules
alsa-utils...
$ cat /etc/udev/rules.d/90-alsa.rules
SUBSYSTEM=="sound", KERNEL=="controlC*" RUN+="/sbin/salsa"
SUBSYSTEM=="sound", KERNEL=="pcm*"      RUN+="/sbin/salsa"
Comment 18 Antonio A. Olivares 2007-08-03 21:04:34 EDT
The volume settings should be automatically restored by udev when the module is
loaded; it is not an initscripts issue.

They SHOULD, but they are not.  Is there any possibility that making a line
similar to fc6's /etc/modprobe.conf which calls /sbin/alsactl -store, true and
instead place /sbin/salsa -l could do the job?  

If it is not an initscripts issue, then how come putting in the line
/sbin/salsa -l
restores sound.  Where is this line?/or where is it supposed to be in the
initscripts?  
Comment 19 Antonio A. Olivares 2007-08-03 22:25:41 EDT
On Fedora 6, the /etc/modprobe.conf on one of my machines looks like

alias eth0 3c59x
alias snd-card-0 snd-ali5451
options snd-card-0 index=0
options snd-ali5451 index=0
remove snd-ali5451 { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; };
/sbin/modprobe -r --ignore-remove snd-ali5451
install slamr modprobe --ignore-install ungrab-winmodem ;  modprobe
--ignore-install slamr; test -e /dev/slamr0 || (/bin/mknod -m 660 /dev/slamr0 c
242 0 2>/dev/null && chgrp uucp /dev/slamr0)

The relevant part being: 

remove snd-ali5451 { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; };
/sbin/modprobe -r --ignore-remove snd-ali5451

all in one line,

[olivares@localhost ~]$ /sbin/alsactl --help
Usage: alsactl <options> command

Available options:
  -h,--help       this help
  -f,--file #     configuration file (default /etc/asound.state or
/etc/asound.names)
  -F,--force      try to restore the matching controls as much as possible
  -d,--debug      debug mode
  -v,--version    print version of this program

Available commands:
  store <card #>  save current driver setup for one or each soundcards
                  to configuration file
  restore<card #> load current driver setup for one or each soundcards
                  from configuration file


Changing this to Fedora 7, the /usr/sbin/alsactl equivalent is /usr/sbin/salsa

with -r and -s r for restore and s for save.  Will try that out and report back.
Comment 20 Antonio A. Olivares 2007-08-03 22:38:30 EDT
puttine in a line into /etc/modprobe.conf like FC6 does not help,
Machines are different, using to compare only and make equivalent 

snd-ali5451 sound device in FC6
remove snd-ali5451 { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; };
/sbin/modprobe -r --ignore-remove snd-ali5451

snd-intel8x0 sound device in Fedora 7  
remove snd-intel8x0 { /usr/sbin/salsa -s > /dev/null 2>! || : ; };
/sbin/modprobe -r --ignore-remove snd-intel8x0

does not work.  Is there something else that we can try?

Thanks,

Antonio 
Comment 21 Martin Stransky 2007-08-06 04:26:34 EDT
Please try to copy these lines to /etc/udev/rules.d/90-alsa.rules

SUBSYSTEM=="sound", KERNEL=="controlC*" RUN+="/sbin/salsa -l"
SUBSYSTEM=="sound", KERNEL=="pcm*"      RUN+="/sbin/salsa -l"

Comment 22 Vivek J. Patankar 2007-08-06 09:38:18 EDT
Done and that partially fixes the problem.
The Master Volume setting is restored but PCM is *not*.
I also tried replacing salsa with alsactl (with appropriate parameters) in
/etc/init.d/halt and /etc/udev/rules.d/90-alsa.rules. The result is the same.
Master Volume is restored and PCM isn't.
alsactl in /etc/rc.local does the job though.
Comment 23 Valent Turkovic 2007-08-06 17:15:39 EDT
I do this:
/etc/init.d/nasd restart

and my PCM volume goes every time back to 50%

this is still a bug for me...
Comment 24 Bill Nottingham 2007-08-06 17:17:51 EDT
That implies a NAS bug. Is anyone seeing this who isn't using nas?
Comment 25 Gian Paolo Mureddu 2007-08-09 10:34:26 EDT
Work around:

add to /etc/rc.d/rc.local

alsactl restore

This is no real solution, but since the Fedora ALSA doesn't include the alsa
initscript for starting and stopping the drivers (which by the way also call
alsactl store and restore) and handled by udev rules (apparently) in the case of
Fedora, you can walk around this issue with the above work around.
Comment 26 Martin Stransky 2007-08-15 11:47:35 EDT
*** Bug 249804 has been marked as a duplicate of this bug. ***
Comment 27 Bastien Nocera 2007-08-20 07:43:09 EDT
*** Bug 243635 has been marked as a duplicate of this bug. ***
Comment 28 Bastien Nocera 2007-08-20 07:44:10 EDT
(In reply to comment #24)
> That implies a NAS bug. Is anyone seeing this who isn't using nas?

I'll add that most people don't want to use NAS, but it's dragged in from the
KDE libs, and the maintainer refuses to split the daemon and its libs. See bug
241378.
Comment 29 Valent Turkovic 2007-09-02 07:07:05 EDT
I have latest updates on my rawhide system and I still see this bug.
Can you please confirm how do you plan to fix it. Thank you.
Comment 30 Gian Paolo Mureddu 2007-09-03 00:58:55 EDT
What would it happen if Fedora enabled by default the ALSA "driver
initialization" init script so it would alsactl store and alsactl restore upon
shutdown and reboot (respectively)? That's the way "kosher" ALSA does its magic,
but in Fedora ever since migrating to ALSA this has been left out (that I could
see, anyway), but when building from source, ALSA installed the alsasound
service which is called upon system boot and again upon system shut down (to
store and restore volume values). Will this cascade down to the new audio
system, pluseaudio?
Comment 31 Bill Nottingham 2007-09-04 10:54:35 EDT
Fedora has loaded alsa mixer settings on boot and saved them on shutdown for the
entirety of its existence - a separate script is not needed.
Comment 32 Gian Paolo Mureddu 2007-09-05 00:31:56 EDT
Since Fedora migrated from OSS to ALSA in FC2 (due to the new sound backend in
the kernel) it was able to do so without the need of the "official" (upstream)
service script, however, and without knowing what's the root cause of this issue
which seems to linger in F8-test, seems the only way to walk around this is by
means of either re-enabling the service script or hand the responsibility down
to udev or some such.
Comment 33 Bill Nottingham 2007-09-05 00:44:59 EDT
In part, I'm somewhat confused because I'm *not* seeing this on any of my boxes.

That being said, it's *already* loaded via udev; that's been what's loaded the
settings on boot for multiple releases.
Comment 34 Valent Turkovic 2007-09-10 08:19:16 EDT
Why don't you just add alsa restore to some existing script until you find a
more in depth solution... please don't let this bug linger forever...
Comment 35 Gian Paolo Mureddu 2007-09-10 23:27:19 EDT
Work around for me is to run alsa restore from /etc/rc.d/rc.local, still running
alsa sotre in any of the shutdown scripts would be nice.
Comment 36 Bill Nottingham 2007-09-11 00:04:58 EDT
As stated before in comment #31, there *is* a call to store the mixer settings
on shutdown, and has been there since the Red Hat Linux days.
Comment 37 Gian Paolo Mureddu 2007-09-11 01:08:21 EDT
If that was the case (and no it wasn't in the RHL days, not that I can remember,
though, those were still the Open Sound System days), how come they are not
restored when only issuing alsa restore after boot up, if you made changes to
your mixer settings (either in alsamixer or gnome-mixer)?
Comment 38 Bill Nottingham 2007-09-11 10:06:36 EDT
(In reply to comment #37)
> If that was the case (and no it wasn't in the RHL days, not that I can remember,
> though, those were still the Open Sound System days)

Trust me, it was the case (the commands have changed some over the years, but
the code is there):

rc.d/init.dhalt: revision 1.18
date: 1999/09/17 15:30:46;  author: notting;  state: Exp;  lines: +6 -0
load/save mixer settings here.

which is RHL 6.1.

, how come they are not
> restored when only issuing alsa restore after boot up, if you made changes to
> your mixer settings (either in alsamixer or gnome-mixer)?

I've just tried again on a fresh rawhide install, and it works fine for me - I
login, change the volume with alsamixer/gnome-volume-control. I then reboot, and
the settings are restored properly.

So, let's go back to the basics. Please attach:

- /etc/alsa/asound.state
- the output of 'amixer' when the volume is *not* restored correctly
Comment 39 Valent Turkovic 2007-09-19 14:24:24 EDT
Created attachment 199901 [details]
asound.state

asound.state
Comment 40 Valent Turkovic 2007-09-19 14:25:06 EDT
Created attachment 199911 [details]
amixer

amixer
Comment 41 Valent Turkovic 2007-09-19 14:29:43 EDT
I installed all the latest updated to my Fedora Devel (Rawhide) system and I
still have this issue.

1. I rebooted the system after updates (new kernel).
2. I opened gnome's Volume Control (Alsa mixer) and set my PCM volume to ~95%
3. I rebooted my system
4. I opened Volume Control (Alsa mixer) and I saw that PCM volume was back on
50% and not 95% as I left it!

This is still an open bug. I already posted the attachments you requested.

Please fix this issue.
Comment 42 Gian Paolo Mureddu 2007-09-19 14:48:19 EDT
On a clean install I watched the shutdown messages carefully and there was a
failed one (you guessed it, saving mixer settings), however this was on a ATI
IXP motherboard with ATI HD audio (which I believe use a different driver than
the one system-config-soundcard picked, I don't think the right driver for this
chip is the Intel HDA), when we get around to installing updates we'll see... We
are having trouble with networking due to known bugs in the RealTek 8139too
driver, and the fact that it is a laptop with an Atheros Wifi card which doesn't
seem to like Madwifi :-/
Comment 43 Bill Nottingham 2007-09-19 15:26:22 EDT
OK, so, examining those attachments:

- /etc/asound.state is correct (main volume 87/89, pcm playback ~95%)

Conclusion #1: settings were saved correctly.

- On reboot, your main volume is restored to 87/89, and your capture volume is
restored to 53%.

Conclusion #2: settings *are* being restored (alsa starts up muted by default)

- However, your PCM volume is 52%.

This means one of two things is happening:

1) alsa isn't reading the value right for PCM when it restores it 

This would be unlikely, as if so, it would almost certainly be setting it to 0.

2) some other service/program is resetting PCM volume to zero.

That's the assumption I'm going with for now. So:

- what services do you have running?
- what programs do you have running in your default gnome session?
- if you log in on the console (instead of GNOME), is the volume also
wrong for PCM?


Comment 44 Bill Nottingham 2007-09-19 15:27:10 EDT
Oops, replace 'resetting PCM volume to zero' with 'PCM volume to 50%'.
Comment 45 Gian Paolo Mureddu 2007-09-19 16:21:06 EDT
> - if you log in on the console (instead of GNOME), is the volume also
> wrong for PCM?

In my case, without my alsa restore hack in /etc/rc.d/rc.local, it does reset to
52% even in an init 3 (in GRUB append a 3 at the end of the kernel arguments to
boot straight into init 3)
Comment 46 Chris 2007-09-19 17:59:09 EDT
Created attachment 200191 [details]
asound.state
Comment 47 Chris 2007-09-19 17:59:58 EDT
I have the same problem with a M-Audio Revolution 7.1
Comment 48 Valent Turkovic 2007-09-30 06:28:43 EDT
I did an new update to my rawhide box and after reboot I got no sound at all!
I ran system-config-soundcard and after another reboot I tested and saw that
this bug is still present.

What more feedback can I give you?
Comment 49 Bastien Nocera 2007-09-30 07:33:43 EDT
(In reply to comment #48)
> I did an new update to my rawhide box and after reboot I got no sound at all!
> I ran system-config-soundcard and after another reboot I tested and saw that
> this bug is still present.
> 
> What more feedback can I give you?

This is completely unrelated to this bug. Make sure ConsoleKit and hal are
running (your user doesn't have access permissions to the /dev/snd/* devices,
ConsoleKit is supposed to give the user access to those devices when logged in).
Comment 50 Valent Turkovic 2007-10-02 13:42:27 EDT
# /etc/init.d/ConsoleKit status
console-kit-daemon (pid 1945) is running...

# /etc/init.d/haldaemon status
hald (pid 2120) is running...


$ ls -al /dev/snd/*
crw-rw----+ 1 root root 116, 8 2007-10-02 19:18 /dev/snd/controlC0
crw-rw----+ 1 root root 116, 7 2007-10-02 19:18 /dev/snd/pcmC0D0c
crw-rw----+ 1 root root 116, 6 2007-10-02 19:18 /dev/snd/pcmC0D0p
crw-rw----+ 1 root root 116, 5 2007-10-02 19:18 /dev/snd/pcmC0D6c
crw-rw----+ 1 root root 116, 4 2007-10-02 19:18 /dev/snd/pcmC0D6p
crw-rw----+ 1 root root 116, 3 2007-10-02 19:18 /dev/snd/seq
crw-rw----+ 1 root root 116, 2 2007-10-02 19:18 /dev/snd/timer


what else?
Comment 51 Dan Williams 2007-10-07 16:39:43 EDT
Gian, Chris, could you attach the output of:

/sbin/chkconfig --list

Comment 52 Gian Paolo Mureddu 2007-10-08 00:01:41 EDT
Created attachment 219021 [details]
Chkconfig --list out put

Here goes the output
Comment 53 Bill Nottingham 2007-10-08 00:22:55 EDT
Gian - what happens if you turn off/uninstall nasd?
Comment 54 Bill Nottingham 2007-10-08 00:27:06 EDT
Actually, never mind. On the basis of comments #23/#24, assigning this where it
should have been since day one.
Comment 55 Bill Nottingham 2007-10-08 00:28:06 EDT
To be honest, I don't even see why NAS is starting by default.
Comment 56 Gian Paolo Mureddu 2007-10-08 03:58:10 EDT
I know NAS got pulled as a dependency for something I installed, problem is that
I don't remember what was it. I have already disabled it, and removed it from
the chkconfig table, will remove my "workaround" in rc.local (alsactl restore)
and reboot, see what happens.
Comment 57 Bastien Nocera 2007-10-08 05:34:50 EDT
(In reply to comment #55)
> To be honest, I don't even see why NAS is starting by default.

Because it's dragged by GStreamer or arts, which is why I filed bug 241378 some
time ago. Maybe I should reopen it...
Comment 58 Luis Villa 2007-10-08 08:06:35 EDT
Notting is right; once I uninstalled nas the problem went away. Apparently I got
it dragged in by installing qt4, though I could swear this was a problem from
day one, and I didn't install qt4 until I'd been running the system for a few
weeks. Odd.
Comment 59 Andre Robatino 2007-10-08 08:33:21 EDT
  According to my install.log, nas was installed during my clean install of F7.
 I didn't do much if any customization of packages so it must be part of one of
the standard package groups.
Comment 60 Solomon Peachy 2007-10-08 11:11:09 EDT
I'm having a similar problem on two different machines running F7.  One has an
boring ATI IXP200M+AC97, while the other has an SBLive board.  Both were
upgraded from FC6.  (technically only the old FC6 homedirs were kept)

On bootup, it remembers all mixer settings except PCM, which is set to rougly
50% on startup.  

The curious thing is that when I run xine to play a random video file, the
volume is reset to 50%.  I set the volume to, say, 90%, quit xine, and restart
it -- the volume is once again set to 50%.  

It would appear that something that xine loads is causing the PCM value to be
reset. 

Xine has an option that allows it to remember the mixer setting and restore it
on startup, but that is *not* enabled.  (If I enable it, xine remembers and
restores the PCM setting to something sane -- but without the option turned on,
PCM gets reset to 50% each time)

I can open a new bug against xine, but this problem seems to be related.  
Comment 61 Solomon Peachy 2007-10-08 13:28:51 EDT
To follow up on my last note -- it appears that loading xine triggers a mixer
settings load; the PCM value stored in /etc/alsa/asound.state is restored each
time I fire up xine.  Is this some sort of udev "reset volume on pcm dev open"
wierdness?
Comment 62 Valent Turkovic 2007-10-31 04:42:20 EDT
Is it reasonable to expect that this bug gets fixed before Fedora 8 ships or not?
Comment 63 Frank Büttner 2007-11-02 08:23:56 EDT
I can't reproduce it on my systems.
I have test it with 3 systems all works ok.
So I think the bug must be at another location.
Comment 64 Bill Nottingham 2007-11-02 11:32:37 EDT
Created attachment 246821 [details]
patch for this issue

No, it's a NAS bug. Perhaps you're not seeing it because your mixer doesn't
have a PCM channel?
Comment 65 Frank Büttner 2007-11-02 11:40:19 EDT
Have you try 1.9a to check if this need the patch to?
Comment 66 Bill Nottingham 2007-11-02 11:48:12 EDT
It has the same code, so I don't see why it wouldn't.
Comment 67 Frank Büttner 2007-11-02 11:52:12 EDT
Ok I build an new package and send the path to the developers.
Comment 68 Frank Büttner 2007-11-02 12:49:09 EDT
I have get an mail from the developer of nas, that patching is unnecessary,
try to change MixerInit "yes" to MixerInit "no" at the config file
/etc/nas/nasd.conf.

Can you test it?
Comment 69 Bill Nottingham 2007-11-02 13:11:29 EDT
Works for me - can we get that changed in the default config? (For F8 updates
too would be nice.)
Comment 70 Frank Büttner 2007-11-02 13:21:31 EDT
Yes.
I will modify it.
Comment 71 Fedora Update System 2007-11-05 10:10:48 EST
nas-1.9a-3.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 72 Fedora Update System 2007-11-06 11:07:56 EST
nas-1.9a-3.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

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