Bug 588585 - Cannot save envy24ctl settings or use alsactl restore have workaround
Summary: Cannot save envy24ctl settings or use alsactl restore have workaround
Alias: None
Product: Fedora
Classification: Fedora
Component: alsa-tools (Show other bugs)
(Show other bugs)
Version: 12
Hardware: All Linux
Target Milestone: ---
Assignee: Tim Jackson
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-05-04 01:40 UTC by Geoff King
Modified: 2010-11-18 02:37 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-11-18 02:37:37 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
alcactl -d output (57.03 KB, text/plain)
2010-06-27 18:18 UTC, Geoff King
no flags Details
the asound.state file you requested is attached (33.66 KB, application/octet-stream)
2010-06-29 01:30 UTC, Geoff King
no flags Details

Description Geoff King 2010-05-04 01:40:02 UTC
Description of problem:
I am unable to save the envy24ctl settings or alsactl with M-Audio 2496 card.  This is an important app for users of this card that are using it for "pro" audio stuff.  For example I want to have the mixers set in a certain position by default.  Instead I have to manually adjust all the settings after each reboot.  

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

How reproducible:

Steps to Reproduce:
1.  change various mixer or other settings using envy24ctl
2.  use sudo alsactl -d store M2496 to store settings to /etc/asound.state file.
3.  use sudo alsactl -d restore M2496 to restore settings 
Actual results:
Step 3 will work under current session, but does not restore settings following a reboot. need to reboot and find that restore does not work.  This is a problem because volume settings are at 0 by default.

Expected results:
Expect the settings to be restored.  

Additional info:
This is procedure I used to figure this out and fix..
 1008  sudo alsactl -d store M2496   [stores settings]
 1009  sudo alsactl -d restore M2496  [should restore, but only gives error after reboot]
 1020  sudo nano /etc/asound.state   
    [can fix this by editing out control.45 section which was causes problem with restore]
    [found to be causing problem by using diff on different stored versions]
    also see similar..

Comment 1 Raymond 2010-06-17 13:45:10 UTC
does it work if you specify -I ?

alsactl -help

                   don't initialize even if restore fails

Comment 2 Raymond 2010-06-17 13:47:38 UTC
post the /etc/asound.state

use -d to debug 

Available global options:
  -d,--debug       debug mode

Comment 3 Geoff King 2010-06-27 18:18:20 UTC
Created attachment 427252 [details]
alcactl -d output

Output from:
alsactl -d restore M1010LT 2> alsactM1010LT.txt

Comment 4 Geoff King 2010-06-27 18:26:43 UTC
In the last week I've changed from the M2496 soundcard to a very similar M1010LT card. This card has the same issue.  I've also noticed that the kernel may be playing a part here also.  I set up (using alsactl) the soundcard on the stock Fedora 12 kernel (2.6.32) and then tried to use it on the CCRMA realtime kernel (2.6.31).  On realtime, I cannot restore any settings, but on the regular kernel it appears I can.  Please see the attachment I just posted.

Comment 5 Raymond 2010-06-28 23:17:33 UTC
To debug the restore function of alsactl,   you should see the debug message (result code, maxnumid, doit and the device ) similar to the following 

alsactl -d restore -f abc.txt

./alsactl: set_controls:1420: device='hw:0', doit=0
./alsactl: set_controls:1432: card-info-id: 'au8830'
./alsactl: set_controls:1458: maxnumid=54
./alsactl: set_controls:1476: result code: 0
./alsactl: set_controls:1420: device='hw:0', doit=1
./alsactl: set_controls:1432: card-info-id: 'au8830'
./alsactl: set_controls:1458: maxnumid=54
./alsactl: set_controls:1476: result code: 0
./alsactl: set_controls:1420: device='hw:1', doit=0
./alsactl: set_controls:1432: card-info-id: 'Intel'
./alsactl: set_controls:1458: maxnumid=49
./alsactl: set_controls:1476: result code: 0
./alsactl: set_controls:1420: device='hw:1', doit=1
./alsactl: set_controls:1432: card-info-id: 'Intel'
./alsactl: set_controls:1458: maxnumid=49
./alsactl: set_controls:1476: result code: 0

Comment 6 Geoff King 2010-06-29 01:30:20 UTC
Created attachment 427543 [details]
the asound.state file you requested is attached

Comment 7 Geoff King 2010-06-29 02:06:05 UTC
Concerning Comment #5, I attached the debug yesterday.  

However, I'm trying this again today after another reboot into the rt kernel and it seems to be working fine now.  Strange

Comment 8 Niels Mayer 2010-09-02 03:58:32 UTC
Note that http://mudita24.googlecode.com (a fork of envy24control(1)) has a working profiles feature that will do exactly what you need. I described this functionality in a recent LAU post http://linuxaudio.org/mailarchive/lau/2010/8/8/172627

On Sat, Aug 7, 2010 at 6:10 PM, Geoff Beasley
<laughingboyrecords.com> wrote:
> Niels, great that you and Tim have fixed this app ;) One thing, can you
> explain what those 'profiles' are for and how to use them?

Envy24control uses the same mechanism as your system does (see
/etc/asound.state and amixer(1)) to save the state of your ALSA
devices between boots. The difference is this mechanism puts the file
under your control at ~/.envy24control/profiles.conf and allows you to
set eight different profiles: allowing you to save or restore up to
eight different "asound.state"-like configurations per card.

The different profiles are most useful for storing routings set in
"Patchbay/Router" panel, as well as "Hardware Settings" panel clock
rate, or external SPDIF/wordclock sync. On cards with switchable
spdif/optical ins (Terratec/Terrasoniq), you can persist this extra
level of "routing" -- which is useful for "matrix routing" between two
digitally-interconnected and sync'd computers. ( I use profiles named:
44dmix-to-1&2&spdif, 48dmix-to-1&2&spdif, spdmix-to-1&2&spdif,
44all-outs-pcm, 48all-outs-pcm, spdif-all-outs-pcm,
96dmix-to-1&2&spdif and 96all-outs-pcm. ).

When you have a combination of settings in envy24control that you want
to return to, just go to the "Profiles" panel, enter the name of the
profile into the first free text field (initially these will be
numbered "1" through "8"). After entering a descriptive name, click
"Save active profile." To restore a given profile, just click on the
"button" area surrounding the text field, or even click within the
text field. You'll notice the selected profile "button" indicates
activation via coloration. After changing profiles, go to, for
example, Patchbay/Router or "Hardware Settings" panels,and  note that
the previously saved state was restored.

Note that significant amounts of setting data gets saved in these files:
> ll ~/.envy24control/
-rw-r--r-- 1 npm npm 115253 2010-08-07 23:10 profiles.conf

For comparison:
> ll /etc/asound.state
-rw-r--r--. 1 root root 128079 2010-08-07 18:15 /etc/asound.state

(That's for a system with two envy24-based cards installed, thus size
is large, causing "save" to produce a brief but noticeable pause in
the metering on a slower system or "ondemand" throttled system).


Comment 9 Raymond 2010-09-02 04:38:40 UTC
(In reply to comment #7)
> Concerning Comment #5, I attached the debug yesterday.  
> However, I'm trying this again today after another reboot into the rt kernel
> and it seems to be working fine now.  Strange

it is because The interface of The "Multi Track Peak" control has been changed from IFACE_MIXER TO IFACE_PCM

so you need to upgrade envy24control 


does mudita24 backward compatible with ice1712 with earlier version alsa-driver before the change

Comment 10 Niels Mayer 2010-09-02 04:53:46 UTC
(In reply to comment #9)
> does mudita24 backward compatible with ice1712 with earlier version alsa-driver
> before the change

Mudita24 was based on trunk version of envy24control, and thus, incorporates the change you mention regarding Multi Track Peak that should be present in updated versions of alsa-tools. I'd assume this fix is also included recent updates of Fedora 12, as well as the stock Fedora13 release.

is the patch to envy24control's trunk (recent), incorporating current 1.03 changes. http://lalists.stanford.edu/lad/2010/08/0059.html is a useful additional patch to 1.03 that will eventually be part of 1.04...

Comment 11 Raymond 2010-09-02 07:06:40 UTC
backward compatible mean can mudita24 work on Fedora 10 or earlier version which "Multi Track Peak" control is still using IFACE_MIXER

Comment 12 Geoff King 2010-09-03 01:30:55 UTC
I consider this fixed for me.  I have not experienced this problem for awhile now. Switching between current FC13 stock kernel ( or FC13 CCRMA realtime kernel (2.6.33) is works.  I'm also using mudita24 with the latest patch (1.03+) and it works fine and also lets me use the presets.  


Comment 13 Bug Zapper 2010-11-03 15:42:50 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

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