You are not logged in.
I've been having problems with alsa on my desktop setup for a while now. A few months ago I had reinstalled arch on my computer, and I noticed that my hdmi audio (It's via a Radeon HD 5450 I think, running on the open radeon module) was broken. I know that the hdmi was my primary sound card from alsamixer. However, alsamixer shows no volume controls for the hdmi device, only a S/PDIF toggle. I thought this was odd, but I ignored it for the moment.
aplay was spitting something along the lines of "unable to open slave: no such file or directory" when I tried running aplay /dev/urandom as a speaker test. I then listed the alsa devices with aplay -L, which gave this output:
null
Discard all samples (playback) or generate zero samples (capture)
hdmi:CARD=HDMI,DEV=0
HDA ATI HDMI, HDMI 0
HDMI Audio Output
default:CARD=VT82xx
HDA VIA VT82xx, ALC888 Analog
Default Audio Device
sysdefault:CARD=VT82xx
HDA VIA VT82xx, ALC888 Analog
Default Audio Device
front:CARD=VT82xx,DEV=0
HDA VIA VT82xx, ALC888 Analog
Front speakers
surround21:CARD=VT82xx,DEV=0
HDA VIA VT82xx, ALC888 Analog
2.1 Surround output to Front and Subwoofer speakers
surround40:CARD=VT82xx,DEV=0
HDA VIA VT82xx, ALC888 Analog
4.0 Surround output to Front and Rear speakers
surround41:CARD=VT82xx,DEV=0
HDA VIA VT82xx, ALC888 Analog
4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=VT82xx,DEV=0
HDA VIA VT82xx, ALC888 Analog
5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=VT82xx,DEV=0
HDA VIA VT82xx, ALC888 Analog
5.1 Surround output to Front, Center, Rear and Subwoofer speakers
I tried playing white noise again, specifiying -D hdmi to aplay, and then it complains about not being able to determine the sample format, yet goes on to list available formats:
aplay: set_params:1233: Sample format non available
Available formats:
- S16_LE
- S32_LE
I specified -f S16_LE, and then it complains "Channels count non available". I specify -c 1, and aplay appears to be playing, but nothing comes from the speakers.
I tried changing both the format to S32_LE and the channel count to 2, but no dice.
At this point I decided to dig into /dev/snd to see what's up. I notice that the usual "default" device node, usually pcmC0D0p, is not there, but pcmC0D3p is:
drwxr-xr-x 3 root root 280 Aug 14 10:29 .
drwxr-xr-x 19 root root 3060 Aug 14 09:55 ..
drwxr-xr-x 2 root root 80 Aug 14 09:55 by-path
crw-rw----+ 1 root audio 116, 2 Aug 14 09:55 controlC0
crw-rw----+ 1 root audio 116, 5 Aug 14 09:55 controlC1
crw-rw----+ 1 root audio 116, 4 Aug 14 09:55 hwC0D0
crw-rw----+ 1 root audio 116, 10 Aug 14 09:55 hwC1D0
crw-rw----+ 1 root audio 116, 3 Aug 14 10:10 pcmC0D3p
crw-rw----+ 1 root audio 116, 7 Aug 14 09:55 pcmC1D0c
crw-rw----+ 1 root audio 116, 6 Aug 14 10:01 pcmC1D0p
crw-rw----+ 1 root audio 116, 8 Aug 14 09:55 pcmC1D1p
crw-rw----+ 1 root audio 116, 9 Aug 14 09:55 pcmC1D2c
crw-rw----+ 1 root audio 116, 1 Aug 14 09:55 seq
crw-rw----+ 1 root audio 116, 33 Aug 14 09:55 timer
Interestingly enough, running strace on a "normal" aplay command without any arguments shows it trying to open /dev/snd/pcmC0D0p, which fails because the device node does not exist.
Just to see if it was an indexing problem, I mv'd pcmC0D3p to pcmC0D0p, and tried running a normal aplay command again. And this time I heard the noise!
Checking in alsamixer, as well as the S/PDIF toggle, a new "PCM" volume meter had appeared for the hdmi card, and it did affect the volume of the noise when changed.
With this fix in place, all my alsa-using applications can play sound successfully. However, I have to manually rename the device node every boot, and something tells me that this shouldn't be happening in the first place.
Does anyone here have any ideas why the contents of /dev/snd are mucked up like this? I have not changed my alsa configuration from the defaults, so I don't think it's a configuration error. Suggestions on how to automate this renaming of the device node would be appreciated, but I'd still like to know if there's a strange bug hiding somewhere.
Edit: Solved, by using the suggestion by emeres to add
defaults.pcm.device 3
to my ~/.asoundrc, now alsa applications open the pcmC0D3p device to play audio, which works perfectly.
Last edited by JMearsXS (2014-08-18 14:58:25)
"Well, this is a fine mess you got me into."
Offline
The card 0 device 3 is from the HDMI sound card, it does not have a device 0, this is quite usual, read "normal". You probably want to set up your second card as default. There are multiple ways of doing this, the wiki info needs to be updated, but modprobe is still recommended. So in your case, it seems both sound cards use snd-hda-intel module, therefore try [edit] the single line below:
$ cat /etc/modprobe.d/50-alsa.conf
options snd-hda-intel index=1 # this is not the correct approach
options snd-hda-intel index=0 # use the line below
Those correspond to their pci/hardware bus placement, run 'lspci -nn | grep -i audio' to see it. Please try using both lines first*, and if after the reboot the HDA VIA is not the default sound card, drop the second line or fuse them into:
$ cat /etc/modprobe.d/50-alsa.conf
options snd-hda-intel index=1,0 # correct approach
Edit: Elaborated a little more and gave examples.
Should you want to continue to use the HDMI as default, you could create/add to ~/.asoundrc:
defaults.pcm.device 3
This would make the default alsa configuration use card 0 device 3 instead of card 0 device 0. Check the output of 'aplay -l' to see cards and devices, the HDMI you have, probably has only device 3. Some newer video cards have a HDMI audio hardware having multiple devices for different sound configurations.
Edit2: Marked the correct and incorrect configuration. *Has been tested, does not work. Use the line where index has both values.
Last edited by emeres (2014-09-06 00:17:36)
Offline
Well now, I edited my .asoundrc as suggested and now hdmi audio works fine. It is interesting that alsa would default to a non-existing device node, however.
Personally I'd like to know how it knows which device node to use, and it seems a little quirky not using device index 0 as the default, but that's getting into black kernel magic...
Also, is there a way of setting the default sound card within asoundrc? I read in your post about setting it via module options, but I'd prefer to do it in my asoundrc as that doesn't require superuser to modify. (If it's in the wiki entry, I'd be glad if you could point me to that!)
EDIT: I've been reading into the docs for asoundrc. Apparently I can specify something like
pcm.!default {
type hw
card n
}
with n being the card number, to set the default sound card, and similarly with ctl.!default for the control device.
I tried setting up the asoundrc in this manner, with an additional "device 3" in the pcm.!default block. From what I understand from the docs, this should accomplish the same thing as the defaults.pcm.device option you mentioned. However, done this way aplay complains again about being unable to determine a sample format. strace shows both scenarios opening /dev/snd/pcmC0D3p, so it should be working. But while a .asoundrc consisting of
defaults.pcm.device 3
works, my attempt at writing one
pcm.!default {
type hw
card 0
device 3
}
ctl.!default {
type hw
card 0
}
does not. Am I doing something wrong here?
Last edited by JMearsXS (2014-08-14 15:54:17)
"Well, this is a fine mess you got me into."
Offline
ALSA does not default to a non-existing device, it is set by /usr/share/alsa/{alsa.conf,pcm/default.conf} to card 0 device 0 subdevice -1. If you want to complain, do that on the alsa-developer mailing list or to gpu manufacturers.
For leaving the default setup intact use the defaults node. To check other possibilities read further, just keep in mind that it needs updating. Reread my previous post.
So you did not use modprobe to set the default sound card? Should you have problems in the future with sound, mention that.
Edit: Have you read the whole chapter, do you realize what using type hw means? You would have to specify more parameters for your current approach. Is it really that difficult to read the wiki from the beginning? Use the defaults.pcm.node, unless you want recreate dmix and dsnoop or some other setup. If you want something more sophisticated, read this.
To elaborate further, by using that deprecated pcm.!default, you overwrite the default setup found in /usr/share/alsa/pcm/default.conf. Read more documentation here.
Last edited by emeres (2014-08-14 16:22:14)
Offline
I have to admit I haven't read all of the documentation, I was skim-reading to try and find a solution.
I didn't realise that pcm.default was deprecated for example.
I guess I ought to read into docs a bit more next time. Thanks for being patient with me, I'll have a read of those links now.
"Well, this is a fine mess you got me into."
Offline
I have to admit I haven't read all of the documentation, I was skim-reading to try and find a solution.
I didn't realise that pcm.default was deprecated for example.
It is fine as an example, anything else would be probably considered too complicated. But it is just that, an example. It could be used for usb DAC, but other than that it leaves you with one sound at a time. I always assumed people would read further and implement this into their unique configuration, but no, they just copy&paste and wonder why sound is blocked. If you really want to use the alsa configuration, use the defaults.pcm node. Remember, that this is for alsa only. It could be problematic with some applications, which is the reason for recommending using modprobe options for setting the default sound card.
And you can always recreate that symbolic link if you want. Plenty of possibilities there, you could even use systemd for this.
Edit: Added frustration for emphasis, nothing personal.
Last edited by emeres (2014-08-14 17:20:08)
Offline
No offence taken. I have been trying to read docs more before asking questions, but I guess impatience for a solution gets to us all eventually
I've been looking through the default alsa configuration files. I has always assumed that alsa was a direct interface to the /dev/snd device nodes. I think I'll have to pay a lot more attention to the docs in future.
Anyway, thanks for the time.
(Oh great, this isn't the best time to mention I don't know how to edit the post title! )
Last edited by JMearsXS (2014-08-15 09:44:08)
"Well, this is a fine mess you got me into."
Offline
Edit the first post and while you are at it, could you specify what you ended up doing to solve your problem? It will be easier to other readers. You are welcome.
Last edited by emeres (2014-08-15 09:56:16)
Offline
I've edited the OP and added a note about the .asoundrc entry to the end of the post. In the end it was
defaults.pcm.device 3
that I used to solve the problem. Works like a charm.
"Well, this is a fine mess you got me into."
Offline