Re: Request for Comments (RFC): Potential change in setting sound card volume on boot
On Wed, 2007-07-04 at 01:02 -0400, Daniel T. Chen wrote: > On Tue, 2007-07-03 at 15:49 -0400, Michael R. Head wrote: > > Should it not be possible to extract the smarts from mixer_applet and > > put it into alsa-utils (or some other startup/shutdown script)? > > Not quite. "Extracting the smarts" would be equivalent to amending > /etc/init.d/alsa-utils to add the appropriate regexp logic so that > levels are maintained across boots with differing element names. Note > that one wouldn't want to place the regexp logic in the initscript > necessarily, since upstream modifies the mixer element strings > frequently (and at times with befuddling consequences, e.g., 'External > Amplifier' toggles). Such a change, of course, would tie the initscript > to the default ALSA version shipped in $release, else we're back to the > current mess. Yeah, putting logically equivalent regexps in multiple places sounds like a bad idea. I guess what I was trying to get at was that maybe mixer_applet's logical mapping (which this argument presupposes is "correct", since that seemed to be what the OP was saying) could be extracted into a library which both mixer_applet and a command line program/init script could both use. Of course, this would take a lot more work and coordination with upstreams. But it's no big deal, of course. It seemed like the proposal was going to cause a regression for folks like me that have had sound levels working fine across boots on a daily basis while fixing a sound level problem that some face when upgrading. It looks like it won't have that big an affect on me, so I'm no longer worried. > Thanks. Thanks for taking the time to explain the technical details. mike -- Michael R. Head <[EMAIL PROTECTED]> http://www.suppressingfire.org/~burner/ http://suppressingfire.livejournal.com http://picasaweb.google.com/demiri.head.wedding smime.p7s Description: S/MIME cryptographic signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Request for Comments (RFC): Potential change in setting sound card volume on boot
On Tue, 2007-07-03 at 15:49 -0400, Michael R. Head wrote: > What I was trying to get at is that if I muted (or turned down) the > volume, when I boot up, it should be at that level before gdm pops up. That is the effect of the current scheme and not the proposed. The effect of the proposed one would be to always mute the Master/PCM/Front/Wave on startup [because no level-sanitisation is performed as it is currently]. > For example, I may reboot my laptop (for whatever reason), in a meeting > or in a library, and if I muted it before rebooting, it shouldn't make > any sound when it boots up. Under the proposed scheme, it would always be muted on a fresh boot. > Should it not be possible to extract the smarts from mixer_applet and > put it into alsa-utils (or some other startup/shutdown script)? Not quite. "Extracting the smarts" would be equivalent to amending /etc/init.d/alsa-utils to add the appropriate regexp logic so that levels are maintained across boots with differing element names. Note that one wouldn't want to place the regexp logic in the initscript necessarily, since upstream modifies the mixer element strings frequently (and at times with befuddling consequences, e.g., 'External Amplifier' toggles). Such a change, of course, would tie the initscript to the default ALSA version shipped in $release, else we're back to the current mess. Thanks. signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Request for Comments (RFC): Potential change in setting sound card volume on boot
On Wed, 2007-06-27 at 15:25 -0400, Daniel T. Chen wrote: > On Wed, 2007-06-27 at 08:32 -0700, Michael R. Head wrote: > > My feeling is that levels > > should be restored before gdm beats its drums (this is particularly > > needful for the "laptops in meetings" case). Further, requiring users to > > modify stuff in etc (or adding a new admin screen with a preference) > > isn't going to work for a more users. This is most important for > > machines with just one user, it's less critical for multi-user machines. > > Just so I understand your response, are you stating that the login sound > for a graphical user login should be _muted_? If so, this is relatively > straightforward to test. Simply move > /etc/udev/rules.d/85-alsa.rules, and reboot. Is the login sound > audible? What I was trying to get at is that if I muted (or turned down) the volume, when I boot up, it should be at that level before gdm pops up. For example, I may reboot my laptop (for whatever reason), in a meeting or in a library, and if I muted it before rebooting, it shouldn't make any sound when it boots up. > > Is there some way to be as smart/correct as the desktop mixer applets > > with respect to level and toggle settings without requiring a user to be > > logged in with the desktop up and running? > > Yes and no. Yes as in the current scheme uses /etc/init.d/alsa-utils > (invoked from the above udev rule) to forcibly set as many matching mixer > elements as possible. It does not require a user to login. No > as in this scheme has its drawbacks as outlined in the original post. Right. alsa-utils isn't smart enough to do it right (or so I gather from the OP). At the same time, the argument seems to be that mixer_applet _is_ smart enough to do things right. Should it not be possible to extract the smarts from mixer_applet and put it into alsa-utils (or some other startup/shutdown script)? > Thanks, > Daniel Chen -- Michael R. Head <[EMAIL PROTECTED]> http://www.suppressingfire.org/~burner/ http://suppressingfire.livejournal.com smime.p7s Description: S/MIME cryptographic signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Request for Comments (RFC): Potential change in setting sound card volume on boot
[Apologies for the delay; I've moved the past few days.] On Thu, 2007-06-28 at 12:21 +0100, Matthew Garrett wrote: > I'm not sure this alleviates number 4 - surely it will always result in > the login sound being muted? mixer_app won't be started until some time > after the sound has started playing. It also leaves us with the issue of > what to do with the GDM sound. Muting that by default would be an > accessibility problem... Yes, thanks for that point. If the udev rule is altered/removed, on the scant half-dozen configurations (hardware-wise, anything from ICH*, EMU10K*, CMI* and USB) I've tested, the Master/PCM level/s is/are initialised to 100% but remain(s) muted. The proposed change would indeed "resolve" the "omgloudsoundbutI'minameeting" issue but certainly represents an unwelcome regression for a11y. I'm open to any suggestions in this regard. Thanks. signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Request for Comments (RFC): Potential change in setting sound card volume on boot
On Tue, Jun 26, 2007 at 09:20:59PM -0400, Daniel T. Chen wrote: > (4) Additionally, users seem split on whether a default login sound in a > graphical environment should be muted[4] or audible. > > To alleviate the issues given above, I am requesting comments from > developers and users alike regarding the following proposal that changes > alsa-utils's initscript usage[0]: I'm not sure this alleviates number 4 - surely it will always result in the login sound being muted? mixer_app won't be started until some time after the sound has started playing. It also leaves us with the issue of what to do with the GDM sound. Muting that by default would be an accessibility problem... -- Matthew Garrett | [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Request for Comments (RFC): Potential change in setting sound card volume on boot
On Wed, 2007-06-27 at 08:32 -0700, Michael R. Head wrote: > My feeling is that levels > should be restored before gdm beats its drums (this is particularly > needful for the "laptops in meetings" case). Further, requiring users to > modify stuff in etc (or adding a new admin screen with a preference) > isn't going to work for a more users. This is most important for > machines with just one user, it's less critical for multi-user machines. Just so I understand your response, are you stating that the login sound for a graphical user login should be _muted_? If so, this is relatively straightforward to test. Simply move /etc/udev/rules.d/85-alsa.rules, and reboot. Is the login sound audible? > Is there some way to be as smart/correct as the desktop mixer applets > with respect to level and toggle settings without requiring a user to be > logged in with the desktop up and running? Yes and no. Yes as in the current scheme uses /etc/init.d/alsa-utils (invoked from the above udev rule) to forcibly set as many matching mixer elements as possible. It does not require a user to login. No as in this scheme has its drawbacks as outlined in the original post. Thanks, Daniel Chen signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Request for Comments (RFC): Potential change in setting sound card volume on boot
On Tue, 2007-06-26 at 21:20 -0400, Daniel T. Chen wrote: > Hi folks, > This change means that volume restoration would be delegated to KMix, > mixer_applet2, and xfce4-mixer (for Kubuntu, Ubuntu/Edubuntu/Ubuntu > Studio, and Xubuntu, respectively). The change resolves issue 1[1], > since at shutdown `alsactl store` is executed, which stores the new > state; also resolved are issues 2[3], 3, and 4[5], since the driver is > responsible for setting a sane toggle. > > Users who elect to continue to restore volume levels at boot can do so > by adding the invocation of `/etc/init.d/alsa-utils start` > to /etc/rc.local. I'm not sold on this part of the solution. My feeling is that levels should be restored before gdm beats its drums (this is particularly needful for the "laptops in meetings" case). Further, requiring users to modify stuff in etc (or adding a new admin screen with a preference) isn't going to work for a more users. This is most important for machines with just one user, it's less critical for multi-user machines. Is there some way to be as smart/correct as the desktop mixer applets with respect to level and toggle settings without requiring a user to be logged in with the desktop up and running? > All the best, > Daniel Chen > > [0] `alsactl restore` is invoked via /etc/init.d/alsa-utils as a RUN > target for each detected audio device. See [4] below. > [1] e.g., https://launchpad.net/bugs/21804 > [2] /var/lib/alsa/asound.state > [3] e.g., https://launchpad.net/bugs/106380 > [4] e.g., https://launchpad.net/bugs/45739 > [5] RUN+="/sbin/start-stop-daemon --start --background > --pidfile /var/run/alsa/bogus --startas /etc/init.d/alsa-utils -- start > %n" -- Michael R. Head <[EMAIL PROTECTED]> http://www.suppressingfire.org/~burner/ http://suppressingfire.livejournal.com http://picasaweb.google.com/demiri.head.wedding smime.p7s Description: S/MIME cryptographic signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Request for Comments (RFC): Potential change in setting sound card volume on boot
On Tuesday 26 June 2007 21:20, Daniel T. Chen wrote: > Hi folks, > > I would like to bring several issues into the glare and to propose a > non-invasive and forward- and backward-compatible (for 6.06 LTS and > Gutsy+1 LTS in particular) resolution to them. > I am particularly interested in further suggestions. Constructive > criticism is always welcome. > I think this proposal makes a huge amount of sense. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Request for Comments (RFC): Potential change in setting sound card volume on boot
Hi folks, I would like to bring several issues into the glare and to propose a non-invasive and forward- and backward-compatible (for 6.06 LTS and Gutsy+1 LTS in particular) resolution to them. (1) For some time now, the Ubuntu alsa-utils source package has shipped a udev rule that restores sound card volume levels on boot[0]. Several Ubuntu releases have seen changes in ALSA's mixer element names. These changes have wrought much weeping and gnashing of teeth[1], because the changes in mixer element names do not correspond to known (at fresh boot into the new kernel) state file[2] fields. (2) Moreover, some users of one family of any particular ALSA driver require one particular mixer setting (on a binary toggle), while users of a newer version of the same family of audio cards _using the identical ALSA driver_ require precisely the opposite mixer setting[3]. (3) Further, users are required to set, to a particular configuration solely dependent on the revision of the audio hardware in the machine, this mixer state. (4) Additionally, users seem split on whether a default login sound in a graphical environment should be muted[4] or audible. To alleviate the issues given above, I am requesting comments from developers and users alike regarding the following proposal that changes alsa-utils's initscript usage[0]: /etc/init.d/alsa-utils will no longer be invoked in the udev rule shipped in the alsa-utils source package (for reference, it is included below[5]). This change means that volume restoration would be delegated to KMix, mixer_applet2, and xfce4-mixer (for Kubuntu, Ubuntu/Edubuntu/Ubuntu Studio, and Xubuntu, respectively). The change resolves issue 1[1], since at shutdown `alsactl store` is executed, which stores the new state; also resolved are issues 2[3], 3, and 4[5], since the driver is responsible for setting a sane toggle. Users who elect to continue to restore volume levels at boot can do so by adding the invocation of `/etc/init.d/alsa-utils start` to /etc/rc.local. I am particularly interested in further suggestions. Constructive criticism is always welcome. Finally, in accordance with the Ubuntu Code of Conduct, because a new job will remove me from consistent Internet access for three consecutive years beginning 9 July 2007, I am resigning from both the community lead for Ubuntu's ALSA maintainership and from Ubuntu core at the end of the Gutsy development cycle. I would like to recognise Luke Yelavich and Toby Smithe in particular whose efforts in improving sound usability in Ubuntu are ongoing. Additionally, my own efforts would not be possible without those of Martin Pitt, Thomas Hood, the remaining Debian ALSA packaging team, the users who frequent #alsa/Freenode, upstream ALSA core itself, and of course, the developers of all Free software I've used. All the best, Daniel Chen [0] `alsactl restore` is invoked via /etc/init.d/alsa-utils as a RUN target for each detected audio device. See [4] below. [1] e.g., https://launchpad.net/bugs/21804 [2] /var/lib/alsa/asound.state [3] e.g., https://launchpad.net/bugs/106380 [4] e.g., https://launchpad.net/bugs/45739 [5] RUN+="/sbin/start-stop-daemon --start --background --pidfile /var/run/alsa/bogus --startas /etc/init.d/alsa-utils -- start %n" signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
