You are not logged in.
Hello. Yesterday I performed a system update as usual, and after rebooting I found that my user account does not have any sound anymore. Root has sound just fine. I checked and my user is still in the audio group. I even removed him from the group, added him again, and rebooted but it did not help.
I get these error messages in a terminal:
mplayer:
alsa-lib: pcm_dmix.c:989:(snd_pcm_dmix_open) unable to create IPC semaphore
speaker-test:
ALSA lib pcm_dmix.c:989:(snd_pcm_dmix_open) unable to create IPC semaphore
Playback open error: -13,Permission denied
Running these with a sudo works 100% fine. Alsamixer levels for my user are normal too.
---------------------
WORKAROUND: Restart timidity service.
SOLUTION: Do not run timidity as a service in the first place.
Last edited by mir91 (2013-11-25 13:37:12)
Offline
Why is your root user playing sound? Unusual.
See config in my sig, for IPC setup such as:
ipc_key_add_uid true
ipc_key 5678293
ipc_perm 0660
ipc_gid audioThe ipc_key is just a random number.
Offline
Thanks for replying.
My root user actually doesn't play sound, I just tried to play some for testing purpose after my normal user suddenly just had silence.
Unfortunately those IPC-changes did not help. However, I removed my /etc/asound.conf file completely for testing purpose and voila, sound suddenly works again. So it seems the last update changed something that does not accept my asound configuration anymore. I will try to experiment a bit with its contents to further narrow it down.
Ok, this is strange ![]()
I commented out an entry
period_time 0
and after that my user had sound again. Then I restored that entry and...sound still works.
I will pretend I didn't see anything and just move along I guess.
Last edited by mir91 (2013-11-17 09:28:59)
Offline
Changes don't instantly take effect - you have to restart the sound-producing app.
Offline
Thanks. Yeah, I did that when testing.
Offline
It seems the asound.conf file was fine. Instead, timidity is the culprit. On my system, it is started as service in the usual way by systemctl.
When I terminate the timidity service, audio becomes usable for user-run programs again instead of root-only.
After terminating it, I can even restart it right away with "systemctl start timidity.service", and it will then magically work together fine with all other user-run media players as you'd expect it to in the first place.
So the solution so far is just a workaround: Do not start timidity.service before the system has "fully booted". If you did, stop the service and restart it again and everything should work again until next reboot.
Last edited by mir91 (2013-11-25 11:38:39)
Offline
Do you actually need the timidity service for anything? I recommend you ask your distro to not enable it at startup - it just gets in the way of a user's ALSA config.
Offline
I installed timidity following the instructions in the arch-wiki in order to be able to play midi-files using sound fonts (fluidr3). It does not mention systemctl invocation, but it is outdated in many places anyway regarding systemctl, so I assumed that systemctl would be the natural way to enable the service nowadays.
Offline
But do you need timidity running as a *service*? As opposed to an app running it as/when needed.
It's bad as a service: Keeping the soundcard open *all* the time is pointless, and prevents things such as updates to ~/.asoundrc from taking effect.
Offline
I wasn't aware it'd behave this erratically, but yes, it seems pretty bad as a service now. ![]()
Despite having solved the issue I'm still curious though why it works once I restart it manually, but restricts sound to root user previous to that.
Last edited by mir91 (2013-11-25 13:36:13)
Offline