Alsactl store function

UNIX for Beginners Q & A
1

Recently, I replaced a codec and amplifier on an older embedded system. It required minor changes to the machine startup code, a new timing crystal and minor alterations to the machine driver. The old amp had a MODE pin which was being used as a mute function and the new amp has a dedicated SHDN pin which can be used as a mute (tested and works). After making the alterations I just eluded to I managed to produce a tone by re-initializing the sound device to a default state by running:

# alsactl init 
# alsactl -f /etc/alsa/asound.play store

I had to alter the new asound.play file slightly (by hand) to make it look as close to the old asound.play file as possible in order to actually produce sound. At some point in the past (old project) someone needed to use the old mute function in order to prevent a "hum" which was being produced by the speaker even when it was supposed to be silent. So they triggered the mute at startup then un-muted when a tone was to be played, waited for the tone to play and triggered it again. Unfortunately, in order to produce a tone with the new CODEC I installed I had to disable that muting behavior :confused:. What I am attempting to do now is to produce sound with that same muting behavior.

Sound is handled in the user-space by a file called SoundManagerAlsa.cpp and I see no reason why I should have to alter that code. It does produce noise but for some reason is not handling the muting functionality the same as it use to. Essentially, in order to mute inside the user-space a GPIO pin which is hooked up to the MODE pin of the amp is being toggled on and off (mute function). The exact same pin can be toggled on and off in order to control the SHDN pin I referred to earlier and like I said that has been tested and it does work. I believe that something about the signal coming into the user-space is slightly different but based on the debugging information (print lines) I enabled inside of SoundManagerAlsa.cpp there doesn't seem to be a difference in the old tone and the new tone. For instance, the frequency is the same, the channel, the pulse width etc. I have no debugger so I can't just step through the code and it's a rather complicated piece of code tbh.

That being said, I believe (is a hunch) that the problem is occurring somewhere prior to the point where SoundManagerAlsa.cpp starts handling sound. So I decided to go take another look at the two .play files again. One thing I noticed: the old asound.play file had a blurb at the top that looked computer generated to me it reads:

#
# Configuration file for the WM8753 with:
#   - Enabled output for the playback functionality
#   - Using the I2S-interface for the data transfer from the uC
#
#

However, my auto-generated default asound.play file for the new codec had no such blurb it just went straight into the declarations of the different features such as:

state.ccwmx51js {
    control.1 {
        comment.access 'read write'
        comment.type INTEGER
        comment.count 2
        comment.range '0 - 63'
        iface MIXER
        name 'Capture Volume'
        value.0 48
        value.1 48
    }
    control.2 {
        comment.access 'read write'
        comment.type BOOLEAN
        comment.count 2
        iface MIXER
        name 'Capture ZC Switch'
        value.0 false
        value.1 false
       }

This got me wondering if there was a way to specify with the alsactl init command if I want things like "playback functionality" or if I want "the I2S-interface for the data transfer..." and such as is noted in the old asound.play blurb I referred to earlier that isn't mentioned in the man pages?