linux 188.8.131.52-0.2-default x86_64
realtek acl1200 codec
Sound for various devices is at best erratic. It is hit or miss whether sound emits at any given time.
Sometimes Flash player (in Firefox) has sound, sometimes not.
Sometimes mplayer has sound, sometimes not. (A workaround for mplayer is to install the ALSA dev package and rebuild mplayer. It still fails on the default channel but succeeds on ALSA.)
The message in mplayer is
[AO OSS] audio_setup: Can't open audio device /dev/dsp: Device or resource busy
“fuser /dev/dsp” returns nothing.
En-/disabling Pulseaudio makes no difference.
I have found no definable pattern to when or not sound works. Usually right after a boot but not always. Sometimes just waiting a while allows whatever to let go of the sound channel. Other times what worked before goes silent.
Using “speaker-test” always works. But then it seems to create the blocked sound problem preventing some other programs from making noise.
I am not even sure what “sound channel” might mean. It appears to be at a high level of abstraction that is easily befuddled. So far, whenever there has been a choice, selecting ALSA access always works. But there is not always a choice.
A better way to determine if some application has seized the audio device, and is not letting it go is to copy and paste into a terminal:
lsof /dev/dsp* /dev/audio* /dev/mixer* /dev/snd/*
note the precise syntax of that.
Note that Linux has had a history of applications not sharing the sound device. This is true for most of the sound servers and daemons in Linux. Which means only one application at a time will be able to play sound with most of the different sound servers and sound daemons. As well often when an application has the sound device, when it closes it may, or it may not, let go of the sound device. When it does not let go of the sound device, all sound is broken until the sound server/daemon is restarted by restarting alsa. Or in other cases when one application (1st) has the sound device and another application (2nd) seizes the sound device from the 1st, when the other application (2nd) is finished with the sound device and releases it, the 1st can not tell that has happened, and it needs to be restarted in order to access the sound device again (via that sound server/daemon in use).
In some cases, it is necessary to restart the alsa sound driver with:
su -c 'rcalsasound restart'
and enter root password, in order to force the 1st device to let go of the sound device. Also after that manually restart one’s mixer (kmix in kde or alsamixer in gnome).
That (single application only for sound) is one of the reasons why pulse audio was introduced. It is supposed to fix this. However pulse audio is buggy for many users.
Note that the alsa application, in addition to providing the sound driver, also provides an API. The alsa API for many different hardware (unfortunately not all) will allow sharing of the sound device. So what I do on my PCs is go into each application’s preferences, and I select ‘alsa’ as the output audio mode. When I do that, and when all my multimedia applications are all using alsa, then they can all share the sound device and multiple applications can play sound at the same time.
As a test I recently had amarok (using the xine engine), vlc and smplayer all playing sound at the same time.
Thanks vodoo. Would you have any suggestions for my issue, which is about audio on HDMI with 11.2/64b and Nvidia Ion (asus eb1501). Unfortunately, Configure-Desktop/Multimedia/Audio-Output orderings of the 3 sound devices on my Nvidia driver (analog, digital & hdmi) seem to have no effect on what programs use as the default alsa device. With the exception of amarok, all programs do not default to hdmi, which is set as the preferred device! After following the guides in this forum, audio works fine in for notifications and test buttons, in amarok (automatically), in smplayer (with easy customisation), mplayer (using command line parameters) and even in the firefox/mplayer-plugin (through customising the conf file with the mplayer command line parameters). However, many hours have not solved the audio routing issues of mplayer-gui, vlc, xine-ui (whose settings always immediately freeze the desktop) and, most importantly of all, firefox/Adobe flash 10 (or chrome/Adobe flash 10). Would you have any thoughts on how to tame firefox/flash to use the hdmi device? many thanks, stuart
For the applications that do not appear/sound to use HDMI, I recommend you check their settings/preferences, as often they provide the capability to over ride what one has set in YaST, and its quiet possible that is the way they are set.
hi oldcpu, thanks for your thoughts. My Yast/Hardware/Sound has only the one main entry, which is “MCP79 High Definition Audio”. Further down in the parameters are “Device HDA Intel” and “Kernel Driver snd_hda_intel”. My desktop is KDE 4.3.4 “release 2” from the KDE43 repo. In Configure-Desktop/Multimedia each of the Audio Output settings has been “preferred” with HDMI so the device order is:
HDA NVidia, NVIDIA HDMI (HDMI Audio Output)
HDA NVidia (ALC662 rev1 Analog)
HDA NVidia (ALC662 rev1 Digital)
thanks oldcpu, I have had analog & digital in the reverse order and it apparently makes no difference. HDMI is device 0,3 and its index remains 3 though it is preferred. This makes me conclude that the problematic applications are probably looking for 0,1 and not the preferred device. I would certainly appreciate your suggestion of a repo for alc662! stuart
oldcpu, in addition to (or instead of) updating the alsa driver with a snapshot, would you concur with modifying the /etc/modeprobe.d/50-sound.conf as suggested in the last post here. Also, perhaps the preceding post to deal with the mplayer-gui problem. thanks, stuart
oh, an update, I tried modifying /etc/modprobe.d/50-sound.conf and mplayer’s config as suggested in the above post and rebooting. Neither was successful (nor seemed to have any effect at all). Thank goodness for smplayer - I return to it often for reassurance that 1080p video and HDMI sound continues to work and is so beautiful that it is worth the effort! Hopefully oldcpu’s suggestion about an alsa snapshot will be the thing to resolve this issue. stuart
Please, please post in this sub-forum, providing in your post the following information:
provide the URLs (of a summary webpage) that are created by running the diagnostic script noted here: SDB:AudioTroubleshooting - openSUSE - Script to run to obtain detailed information. On openSUSE-11.1 and newer that will ask you to run the script /usr/sbin/alsa-info.sh and after the script finishes it will give you a URL to pass to the support personnel. Please post here the output URL. Just the URL. You may need to run that script twice (the first time with root permissions to update in the /usr/sbin directory, and the second time to get the URL).
in a terminal, or xterm, or konsole, type: rpm -qa ‘alsa’ #and post output here
in a terminal, or xterm, or konsole, type: rpm -qa ‘pulse’ #and post output here
in a terminal, or xterm, or konsole, type: rpm -q libasound2 #and post output here
in a terminal, or xterm, or konsole, type: uname -a #and post output here
for openSUSE-11.1 or earlier, in a terminal, or xterm, or konsole, type: cat /etc/modprobe.d/sound #and post output here
*] for openSUSE-11.2 or later, in a terminal, or xterm, or konsole, type: cat /etc/modprobe.d/50-sound.conf #and post output here
hi oldcpu, in regard to updating alsa, the latest alsa 184.108.40.206 does seem to have a number of HDMI fixes of the type apparently needed. According to Alsa-update-snapshot “Daily snapshots openSUSE-11.2”, two updates are required. The first doesn’t seem to exist. Only 11.1 & Factory directories are available. The second does exist but has slightly older kernels (220.127.116.11 as compared to 18.104.22.168). Could using this older kernel cause major issues? Anyway, given the first problem, perhaps an alsa snapshot update can only be achieved through Factory? If this is the case, might there be an additional complication because Factory has moved on to the next kernel 2.6.32? many thanks, stuart
Typically one can try:
(1) updating all alsa apps and libasound2 from Alsa-update - openSUSE without the alsa-driver-kmp-desktop, reboot and test
(2) keep (1) installed and also install alsa-driver-kmp-desktop and then reboot and test;
(3) updating all alsa apps and libasound2 from Alsa-update-snapshot - openSUSE without the alsa-driver-kmp-desktop, reboot and test
(4) keep (3) installed and also install alsa-driver-kmp-desktop and test.
However (2) and (4) (ie Alsa-update-snapshot - openSUSE ) is not available yet for 22.214.171.124 , so IMHO it is simply best to wait for a couple of weeks. Its quite possible the openSUSE sound packager is away on a ski holiday, or some other vacation.
Yes it could cause major issues.
No, note only use the factory with the factory 2.6.32 kernel.
Yes, there would be an additional complication due to the 2.6.32.
IMHO, wait a week or two and lets see what develops.