Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 588585 - Cannot save envy24ctl settings or use alsactl restore have workaround
Cannot save envy24ctl settings or use alsactl restore have workaround
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: alsa-tools (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Tim Jackson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-03 21:40 EDT by Geoff King
Modified: 2010-11-17 21:37 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-17 21:37:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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 14:18 EDT, Geoff King
no flags Details
the asound.state file you requested is attached (33.66 KB, application/octet-stream)
2010-06-28 21:30 EDT, Geoff King
no flags Details

  None (edit)
Description Geoff King 2010-05-03 21:40:02 EDT
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):
1.0.22-1

How reproducible:
Always

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..
    http://mailman.alsa-project.org/pipermail/alsa-devel/2010-February/025694.html
Comment 1 Raymond 2010-06-17 09:45:10 EDT
does it work if you specify -I ?

alsactl -help


 -I,--no-init-fallback
                   don't initialize even if restore fails
Comment 2 Raymond 2010-06-17 09:47:38 EDT
post the /etc/asound.state

use -d to debug 


Available global options:
 
  -d,--debug       debug mode
Comment 3 Geoff King 2010-06-27 14:18:20 EDT
Created attachment 427252 [details]
alcactl -d output

Output from:
alsactl -d restore M1010LT 2> alsactM1010LT.txt
Comment 4 Geoff King 2010-06-27 14:26:43 EDT
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 19:17:33 EDT
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-28 21:30:20 EDT
Created attachment 427543 [details]
the asound.state file you requested is attached
Comment 7 Geoff King 2010-06-28 22:06:05 EDT
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-01 23:58:32 EDT
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).

Niels
http://nielsmayer.com
Comment 9 Raymond 2010-09-02 00:38:40 EDT
(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 


http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=2bdf66331c3ff8d564efe7a054f1099133d520cd


does mudita24 backward compatible with ice1712 with earlier version alsa-driver before the change
Comment 10 Niels Mayer 2010-09-02 00:53:46 EDT
(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.

http://nielsmayer.com/envy24control/mudita24-envy24control-0.6-to-1.0.3.patch
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 03:06:40 EDT
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-02 21:30:55 EDT
I consider this fixed for me.  I have not experienced this problem for awhile now. Switching between current FC13 stock kernel (2.6.34.6-47.fc13.i686) 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.  

Geoff
Comment 13 Bug Zapper 2010-11-03 11:42:50 EDT
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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