alsactl error with kernel 3.7.1 on Slackware-current
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
alsactl error with kernel 3.7.1 on Slackware-current
Noticed the following startup error after updating my slackware-current test partition to 3.7.1
Code:
alsactl: set_control:1464: Cannot write control '3:3:0:Playback Channel Map:0' : File descriptor in bad state
The sound works until I run a couple of games under wine, then it starts to crackle at first, then disappears by the time I launch another game. Problem goes away when I reboot with 3.6.11 or 3.2.29
Anyone else running 3.7.1 and having the same error?
Noticed the following startup error after updating my slackware-current test partition to 3.7.1
Code:
alsactl: set_control:1464: Cannot write control '3:3:0:Playback Channel Map:0' : File descriptor in bad state
The sound works until I run a couple of games under wine, then it starts to crackle at first, then disappears by the time I launch another game. Problem goes away when I reboot with 3.6.11 or 3.2.29
Anyone else running 3.7.1 and having the same error?
Same error here. I haven't found any solution yet.
I get the same annoying error. Tried to fix it deleting /var/lib/asound.state and regenerating it with alsactl store. It works... but when I do alsactl restore (as does rc.alsa every boot), it gives me the error again.
Code:
alsactl: set_control:1464: Cannot write control '3:3:0:Playback Channel Map:0' : File descriptor in bad state
alsactl: set_control:1464: Cannot write control '3:3:0:Playback Channel Map:0' : File descriptor in bad state
alsactl: set_control:1464: Cannot write control '3:7:0:Playback Channel Map:0' : File descriptor in bad state
alsactl: set_control:1464: Cannot write control '3:8:0:Playback Channel Map:0' : File descriptor in bad state
alsactl: set_control:1464: Cannot write control '3:9:0:Playback Channel Map:0' : File descriptor in bad state
If after upgrading kernel you run 'alsactl store' as user it cannot replace old /var/lib/alsa/asound.state and 'alsactl restore' will complain after reboot.
If after upgrading kernel you run 'alsactl store' as user it cannot replace old /var/lib/alsa/asound.state and 'alsactl restore' will complain after reboot.
If you ran it as user, that's not the kind of error you will get...
If you ran it as user, that's not the kind of error you will get...
If you get errors after upgrading kernel, then run 'alsactl store' as user instead of root, you still continue getting the same errors from 'alsactl restore' on reboots.
If you get errors after upgrading kernel, then run 'alsactl store' as user instead of root, you still continue getting the same errors from 'alsactl restore' on reboots.
How are you able to run 'alsactl store' as user instead of root ???????
$ /usr/sbin/alsactl store
/usr/sbin/alsactl: save_state:1608: Cannot open /var/lib/alsa/asound.state for writing: Permission denied
Even if user type
Code:
$ alsactl store
-bash: alsactl: command not found
result is the same. In both cases /var/lib/alsa/asound.state stays unchanged and 'alsactl restore' still complains after reboot.
That's incorrect. In one case (simple user case), the alsactl didn't even execute, while in the other it failed to write the asound.state. The point is there is no way you can run alsactl without root privileges in Slackware, AFAIK.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.