alsa mixer Multi Track Internal Clock stuck on IEC958 and operation error

Bug #86325 reported by Joshua Timberman
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
alsa-utils (Debian)
New
Undecided
Unassigned
alsa-utils (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: alsa-utils

The mixer in Volume Control, the asound.state file (after alsactl store) and alsamixer all show

Multi Track Internal Clock set to 'IEC958 Input'

despite the following setting in an asound.state file I am trying to restore. (value 44100).

        control.43 {
                comment.access 'read write'
                comment.type ENUMERATED
                comment.count 1
                comment.item.0 '8000'
                comment.item.1 '9600'
                comment.item.2 '11025'
                comment.item.3 '12000'
                comment.item.4 '16000'
                comment.item.5 '22050'
                comment.item.6 '24000'
                comment.item.7 '32000'
                comment.item.8 '44100'
                comment.item.9 '48000'
                comment.item.10 '64000'
                comment.item.11 '88200'
                comment.item.12 '96000'
                comment.item.13 '176400'
                comment.item.14 '192000'
                comment.item.15 'IEC958 Input'
                iface MIXER
                name 'Multi Track Internal Clock'
                value '44100'
        }

I am also getting an error using the file for restore for another stanza; this may be why its not updating...

$ sudo alsactl -f asound.state.allworking restore
alsactl: set_control:1068: Cannot write control '2:0:0:IEC958 Output Switch:0' : Operation not permitted

        control.51 {
                comment.access 'read write'
                comment.type BOOLEAN
                comment.count 1
                iface MIXER
                name 'IEC958 Output Switch'
                value true
        }

Revision history for this message
Joshua Timberman (jtimberman) wrote :

Full asound.state file I am using is attached.

Revision history for this message
Necromancer (d-smirnoff) wrote :

I also experience the same kind of behaviour on gutsy beta with M-Audio Revolution 7.1 card. Can't get the sound working.

Revision history for this message
Andreas Moog (ampelbein) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with latest Ubuntu release? Thanks in advance.

Changed in alsa-utils:
assignee: nobody → andreas-moog
status: New → Incomplete
Revision history for this message
Joshua Timberman (jtimberman) wrote :

I no longer have the hardware that this problem occurred on, so I cannot do any further testing. Thank you.

Revision history for this message
Andreas Moog (ampelbein) wrote :

Closing this bug then but don't hesitate to submit bug reports in the future. Thanks again!

Changed in alsa-utils:
assignee: andreas-moog → nobody
status: Incomplete → Invalid
Revision history for this message
defce (romanticrecords) wrote :

This exact bug has also happened to me ... whilst configuring sound using pulse audio and an maudio 2496 sound card ... using jaunty 9.04

Revision history for this message
Andreas Ntaflos (daff) wrote :

I just ran into this bug as well. Using Kubuntu 9.04 (KDE 4.2.4) and an Maudio Delta Audiophile 2496. The funny thing is that this is a quite fresh install and everything worked fine until a day ago when I installed, then uninstalled some gstreamer-related packages (libgstreamer0.10-dev, gstreamer0.10-alsa, ...). Then suddenly the soundcard was not recognized at all anymore. I had to power down the machine, remove the card, power it up again, then repeat with the card reinserted. But now the internal clock rate is stuck at ICE958 (the S/PDIF) which I don't use so the card has no valid clock rate set. This results in no output at all from the soundcard and applications that play sound freeze one way or the other.

Even funnier is that I just rebooted and had a look at alsamixer on a virtual console, i.e. *before* logging into KDE. There it was no problem to set the internal clock rate to something other than ICE958. I set it to 96000 and tested with aplay /usr/share/sounds/k3b_success.wav which worked fine.

*Then* logging into KDE I found that the problematic control was stuck again and there was no way to set it to anything else. I have no idea if this is KDE-specific (Phonon?) or a general problem with desktop environments that provide some level of control over the sound hardware/API. But it definitely depends on whether KDE is running or not: logging out and checking alsamixer on a virtual console I was able to set the internal clock rate again.

I am not sure how to debug this properly or what part of KDE is responsible here.

Revision history for this message
defce (romanticrecords) wrote :

in order to modify the clock rate i had to uninstall and reinstall pulseaudio. I am now very careful about touching the clockrate ;)

Revision history for this message
Steven Koskela (dharmamarx) wrote :

I just ran into this bug on Ubuntu (not Kubuntu) and man is it awful! Reinstalling alsa-base and/or pulseaudio did nothing to fix it. I was able to fix it, though, by doing: sudo alsa force-reload. (Reloading my asound.state file and running sudo alsactl restore may have also helped.)

Revision history for this message
Sebastian Schultz (god2blief) wrote :

After resuming from "suspend to RAM" I have the same problem, "sudo alsa force-reload" is helping. Two years since first report..FIX IT!

Revision history for this message
Sebastian Schultz (god2blief) wrote :

I changed to debian testing & KDE, until KDE 4.3 the "sudo alsa force-reload"-methode worked for me, but since I moved to KDE 4.4 (and gstreamer as phonon-backend, xine isn't working anymore) the Multi Track Internal Clock is stuck at 16000. Now I have to reboot to fix this problem. Come on guys, fix this bug!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.