Getting sound from NVidia desktop video card to TV over HDMI
 

How do I get HDMI audio working? I'm connecting an NVidia GTX 760 video card to a TV over HDMI. Video is going over the HDMI cable; I'm trying to get audio over the HDMI cable too.

I've attached a screenshot of what I see in alsamixer if I press F6 to select the sound card built into the video card. As you can see, I can unmute the channels, but I can't set their volumes above zero.

I should mention that when I boot into Windows, audio over HDMI just works. I say this not to whine, but because I think it's relevant to troubleshooting.

Here's my aplay -l

And here's my aplay -L:

I'm using the binary NVidia drivers, of course.

Greetz
I have essentially the same card but I don't have anything I can plug HDMI into to test audio but I am very curious as to how this thread turns out since I expect to remedy that shortly. I do have an idea that I have yet to check out and that is I am wondering if the nVidia driver also normally supports the HDMI audio and therefore provides some sort of conflict with ALSA? I'm going to look through the rather comprehensive and helpful nVidia driver documentation to see if this is so and what switches might be applied. Perhaps you might wish to peruse those as well. In any case if I find something I'll write back but still depend on you since you can actually test it out. Good fortune.

Yes, the nvidia drivers for Linux do support HDMI audio.
Unless someone has come up with a recent solution, setting up HDMI in Linux is not an easy task and not everything will work, e.g., some applications might be able to use HDMI and other may not.

Update.

I don't have it working yet, but these commands are all working and sending sound to the HDMI-connected TV:

I got them from here: http://ubuntuforums.org/showthread.php?t=1668737

Several guides have recommended setting a probe_mask option on the Intel driver. I haven't been able to investigate that yet, but here's what I get for grep valid /proc/asound/NVidia/eld*:

The setup is of ALSA, so wouldn't it work with every application that outputs audio through ALSA?

I've had some luck using Pulseaudio to control where the sound goes on my laptop with nvidia...

Set up Alsa to use the HDMI output as default (info how to do that here).
Easier, but a sacrilege for some people: Just install Pulseaudio and let it route audio to whichever output you want, including changing the output on the fly.

The best option is to just disable the onboard audio if possible. This will allow udev to detect only the HDMI processor and use the Intel HD Audio. It also helps if you have a PCI/PCIe audio card that uses a different chipset as well.

Yes, using PulseAudio is easier, but you should learn, at least, how to properly configure ALSA and dmix properly.

.asoundrc in HOME
i think, and may be wrong, that this is direct routing
so if two sound sources have different sample/bit rate then only the first one will get through
expanding the config would sort that out, if it happens (i think its the ctl part, not sure)

PS flash may also not work
an udev rule to put nvidia interface as the first one (0) would fix that

edit: as per wiki that TobiSGD linked, this might work if the one above does not

I tried that approach. It didn't work, and I abandoned it before doing any analysis beyond "it didn't work."

Some of us just want to use our computers rather than digging around and editing config files - which is why I mentioned that PulseAudio had worked for me...

I have had the same issue; I found the first ~/.asoundrc file mentioned by genss in post #8 didn't work, but the second one did (with some tweaking):
I have it saved as ~/.asoundrc-hdmi so when I plug the hdmi cable in I just cp ~/.asoundrc-hdmi ~/.asoundrc

I won't be able to try out the recommendations until tonight (most likely tomorrow), but I do need to ask, enorbet: will your Slackware Box be an HTPC or a Steam Machine?

device numbers are based off of aplay -l from the first post

card0 is whatever was initialized first on the system
every card has subdevices, like my card0 has "device 0: Multichannel [Multichannel]" and "device 1: Digital [Digital]"
udev, i think, is the one that initializes the cards but there is something about alsa configs (never digged deep enough)

NVidia (ftp://download.nvidia.com/XFree86/gp...dmi-audio.html) mentioned that chipsets are Card 0 and discrete cards are Card 1.

I suppose the short answer is, as it is pretty much all the time, some mongrel :)

I'm using an old Olevia 27" HDTV for a monitor which, although it has an HDMI input, the docs say only the VGA input can be used for PC. It's a decent amount of screen real estate but it's resolution is no great shakes - limited to 1280 x 720. I am an avid gamer so I have many versions of Steam installed through PlayOnLinux but I also have Pipelight for streaming. I do have an interest in trying out the Steam OS after it gets dry behind the ears, but no rush on that as presently the only reason I have left to boot to Windows is for parts of audio recording/editing work. I do as much as I can with Ardour, and have since it first came out as Alpha software, but unfortunately some initial work still takes windows apps and plugins.

Hold that thought on there and let me explain...

Part of using GNU/Linux first involves learning GNU/Linux which actually involves reading documentation, editing configurations files, and trial and error with scripting. In order for you to use a system, you have to first learn it, otherwise you may have either picked the wrong distribution, or even the wrong operating system.

GNU/Linux, regardless of distribution, is not an operating system with an "easy" button. If you want "easy button" operating systems, there's always OS-X and Windows. Slackware also, is far from being an "easy button" Linux distribution also. You have to learn before you can use.

Patience grasshopper... the grass must first grown before it can be eaten.

And PulseAudio doesn't always work. Sometimes even PulseAudio can not fix what proper scripting and configuration files can accomplish.

Well, this (copy-and-pasted exactly) worked perfectly!

The "more configuration might be necessary to get it working with Flash" turned out to be unfounded; Flash works fine with it.

Whoa. I'm starting to experience massive A/V sync issues on HDMI over ALSA. And by "massive", I'm talking about three seconds of delay between the video and the audio.

EDIT: a reboot fixed it. I don't know what happened.

EDIT 2: This seems to be reproducible if I close a Chrome tab with a running Youtube movie in it.

Nice to have added to the Slackware wiki perhaps?

Eric

I don't know why I said Flash was sending audio through HDMI. It wasn't, in any WM/DE. Did I think HTML5 Youtube was Flash?

Anyway, I fixed that for everything except Flash in KDE. This is what I now have in my .asoundrc:

In Xfce and other WMSs, everything is sending audio over HDMI: Flash (trailers on steampowered.com or anime on Crunchyroll), HTML5 in Chromium, Wine games (Warcraft 3), native Linux games in Steam, Mplayer, etc.

In KDE (where I had to set NVidia audio device to be preferred and set my playback backend to MPlayer), everything is sending audio over HDMI except Flash.

At this point, I'll probably give up on KDE and just stick with my usual OpenBox desktop.

Can anyone who's using Pulseaudio for this confirm that it lets Flash send audio over HDMI, in KDE? I'm not going to test it myself.

I think I solved it.

• completely tested in KDE (4.12.5 on 14.1, 64-bit)
• no stuttering in Warcraft 3
• no stuttering in MPlayer over ALSA
• aoss mplayer -ao oss works
• KDE sound notifications work after I set the audio device priorities (kept the backend as GStreamer)
• Towerfall Ascension in Steam works
• trailers on steampowered.com (Flash) work in Chromium
• Youtube (HTML5) works in Chromium
• software mixing through DMix works (this was missing from my prior attempts!)

That covers all the main cases and all the edge cases.

I drew on this, which honestly worked even just copy and pasted:

https://bbs.archlinux.org/viewtopic....789152#p789152

And this:

http://alsa.opensrc.org/Dmix

I chose to use card 1, device 3. Card 1, device 7 (which is what the Arch Linux post uses) also works. The period_size and buffer_size are taken from the Arch Linux post, and I found that the combination of the two was necessary to get non-stuttering audio in both Warcraft 3 and MPlayer.

I admit that I've probably proven the "dude, just use Pulseaudio" point. Whatever.

And I still sometimes get weird bugs where the audio gets permanently delayed by anywhere from half a second to 3 seconds. In those cases, it seems that all I can do is reboot. I don't know what's going on with that or whether it's solvable.

I apologize for making this thread so bloggish.

Anyway, with the above settings I was consistently getting delayed audio in Runner2. I just had to play two levels, and then the audio would start playing 2-3 seconds late. I also got low frame rates in some levels. A Google search mentioned that delayed audio could be caused by too small a buffer. So I tried increasing the buffer size in the .asoundrc, and also added the bindings section to optimize for speed. That fixed both issues. I hope that this also solved my general issue of audio getting delayed (well, it has so far). The new .asoundrc is this:

One of my goals is to have the simplest .asoundrc that would actually work; I don't want anything in it that you could remove without consequence. Therefore, I've still left out the sample rate and sound format specifiers that were used in the Arch Linux post.

i don't have hdmi
try making a file /lib/modprobe.d/alsa.conf containing
where the module is from
lsmod | grep snd
it's the one that uses "snd" and is probably called something like "snd-hda-nvidia"
note that udev might get smart and not comply

with that you don't need .asoundrc

other thing that comes to mind, even dirtier, is blacklisting the other soundcard driver (module)
that is done in /lib/modprobe.d/blacklist.conf
like
or whatever it's name is from lsmod

edit: you need to reload those modules, simplest way is to reboot (other way is rmmod and modprobe them bout, and maybe some they use if any)


while im at it, the dmix buffer sizes (same as alsa, but alsa ones are by the app)
period = how much data to receive/send at a time, in frames (frame_size = bitrate/8*channels bytes)
buffer = total size of buffer, in frames
latency = 1/(sampling_rate/frames) s
so for a 48khz sound and 1024 frames period and 8129 frames buffer it comes to ~21.33ms (~0.021sec) minimum with maximum of 8x that much

ofc bout of those would be better lower, but cpu consumption raises
lowering the buffer might get the best of bout worlds, to something like 4096
(so there are 4 buffers(periods) to fill in the circular buffer)

if you find that useful somehow

Current NVidia cards have Azalia chips on them. They use the snd-hda-intel driver.

I'm now aware of the following:

The period_size should be as small as possible, and just large enough to, when combined with the buffer_size, not cause problems such as stuttering. The reason is that period_size translates directly into latency. It needs to be a power of 2.

The buffer_size needs to be a multiple of the period_size, and needs to be large enough so that, when combined with the period_size, it does not cause problems such as stuttering or delayed audio.

The period_size and buffer_size are both directly related to the sample rate.

Therefore, I've revised my .asoundrc as follows:

The lower latency is noticeable and makes Runner2 better.

(I also realized that the "bad performance" I'd been complaining about before was caused by CPU frequency scaling).

Never say this post is too bloggish Dugan. Providing direct answers and WIP answers is what solving problems and developing solutions is about.

More progress.

Warcraft 3 in Wine actually tries to open a "recording" device. I adjusted the .asoundrc to add one, so that Wine doesn't complain.

I also determined the smallest period and buffer sizes that I can get away with without getting problems. This gives me the lowest possible latency, and it hasn't caused problems so far.

It's a good thing I didn't listen to the people who told me to just disable the motherboard sound card. As you can see, I needed it to be the recording device.

Update: Well that's interesting. Videos in Firefox (HTML5 Youtube) are silent. Nothing that might indicate what the problem is is printed to the console. And if I have Firefox play an ogg file from /usr/share/sounds, I hear it. No, the videos are not muted.

Still getting regular issues where the audio permanently gets delayed by 1-3 seconds. I'm still trying to figure that out.

As for the audio delay issue, I saw something in my dmesg output and googled for it. After seeing this:

https://bugs.launchpad.net/ubuntu/+s...r/+bug/1181721

I added the following to /etc/modprobe.d/alsa-base.conf

We'll see if it helps anything.

EDIT: it fixed the dmesg warning, and I'm tentatively going to say that it seems to help with the sync issue.

My audio delay issues (and again, I'm talking 1-3 seconds of delay, for all apps, with the problem starting after some audio has been played, paused, closed, etc) are caused by issues at either the hardware or kernel module level, not at the dmix level, aren't they?

How would I debug this? The only relevant thing I've ever seen in dmesg is what I covered in the previous post. Google hasn't turned up a similar issue. The problem has (so far) not recurred since I set the kernel module options in the previous post, but I also haven't tested enough since then to be confident that it won't. UPDATE: it's recurred, but it seems to be happening less often now.
-
Debugging recommendations I've seen online include rebuilding the snd-hda-intel driver (which the audio chip on my NVidia card uses) to enable more logging (http://www.tldp.org/HOWTO/Alsa-sound-7.html), and using a parameter in proc to enable more logging (http://www.alsa-project.org/main/index.php/XRUN_Debug). While I haven't tried these yet, I am neither an ALSA developer nor a sound card engineer, and I'm not sure if I'd know what to do with the information.

I not yet tested to see if the problem happens in Windows. I'm not really ready to go back to Windows right now, even temporarily. :)

I have not tested with a newer kernel (which should be enough to upgrade the ALSA drivers).

I'll test without DMIX only if there's a really compelling reason to (to narrow down the cause of a problem, for example); you need DMIX for real world use.

I'm using a current stock Slackware kernel, and the current binary nvidia drivers from SlackBuilds.org.

I was still suffering from audio desyncs as of yesterday. Today, I thoroughly read NVidia's HDMI Audio on NVIDIA GPUs document. It made me realize that I'd made at least one significant mistake (outputting to the wrong device) I also read the XRun Debug ALSA document, which I hoped would help me determine if the period_size and buffer_size values were faulty.

First I upgraded to the latest stable kernel (3.15.4) and the latest NVidia driver (340.24). You never know when an upgrade like this is all that's needed to solve the problem.

When building the kernel, I enabled XRun debugging:

I know, at this point, that my video card's audio chip is card 1. Once I got everything back up, and was back in my OpenBox desktop, I went to ls /proc/asound/card1:

• codec#0
• eld#0.0
• eld#0.1
• eld#0.2
• eld#0.3
• id
• pcm3p
• pcm7p
• pcm8p
• pcm9p

got me:

As you can see, the second ELD is the one that's valid. That means that the device I need to use is the second one. Any device other than the one whose ELD lists it as valid should be considered to be either nonworking or only partially working. The working device, therefore, is pcm7p. That's device 7, and not device 3 like I had before. So I revised my .asoundrc to use card 1, device 7:

I also turned on ALSA buffer overrun/underrun debugging by adding the following to /etc/rc.d/rc.local:

Overkill, no doubt. :)

The problem hasn't recurred yet, so I don't have any debugging data yet (I assume it will appear in dmesg), but I think I'm on the right track.

You know what? I give up. I got the one second of audio lag again today. There was nothing in my dmesg output as to why. At this point, I think I've exhausted all the options.

No worries; my new setup will be video over HDMI, audio from a Behringer UCA 202 USB sound card directly to speakers. It just makes it a bit more complicated if I want to hook other devices up to the TV.

EDIT: Hmm... the problem went away soon after I posted, suggesting that it's temporary. Still not something that I'm willing to deal with.

Well, you took it a lot farther than I did. :)
A year or two ago I spent a good amount of time trying to get HDMI audio to work after reading the documentation from NVIDIA and elsewhere and finally threw in the towel. :scratch:
Kudos for all the effort you put into the project.
:hattip:

So, did you try it with Pulseaudio?

No. Is it as simple as following the README on SlackBuilds.org, and then setting the following .asoundrc?

https://projects.archlinux.org/svnto...ulseaudio-alsa

Should be. To be honest, I can't remember to even have a .soundrc on Slackware with Pulseaudio and I definitely don't have one now on Gentoo.

Got help from this thread. SOLVED] Proper pulseaudio setup for Slackware64-current They were:

Install alsa-plugins as well as pulseaudio

Add start-pulseaudio-x11 to ~/.config/openbox/autostart (because I'm using openbox)

Add to /etc/rc.d/rc.local:

Make /etc/rc.d/rc.pulseaudio executable and start it up

Add the following ~/.asoundrc

Pulseaudio is now working so transparently that I can't even tell if I'm outputting audio through Pulseaudio. I suppose that's a good problem to have. I'll post back if I get the lagging audio again, or if I manage to go for a week without it.

UPDATE: Hate to turn this into a Pulseaudio thread, but ugh... it turns out (ref) I need both a compat32 pulseaudio and a compat32 alsa-plugins to get audio in Wine now. I'll take care of that later.

UPDATE 2: Runner2 crashed immediately for what I strongly suspect is the same reason:

I'll try to take care of these tomorrow.

Tobi, were you able to get Bit Trip Runner2 working with Pulseaudio? I got this problem, and I can't fix it:

http://steamcommunity.com/app/218060...8810978055856/

Everything else I've tried (including other Steam games) works.

Hey ReaperX7. The reason this doesn't work is because ALSA's default output device is card 0, device 0, or 0:0. The devices on my discrete NVidia card, as you saw from my aplay output, are 3, 7, 8 and 9, with 7 being the "valid" one (that's what my ELD info said, as mentioned upthread). If you have the motherboard's audio interface enabled, then the NVidia sound card is card 1, and its devices are 1:3, 1:7, 1:8 and 1:9. Disabling the motherboard sound card simply shifts the NVidia card's number to 0, giving you four audio devices: 0:3, 0:7, 0:8 and 0:9. None of these are 0:0, and you'll therefore get no audio output unless you do further tweaking.

You can then use the following .asoundrc to set device 0:7 as the default:

But then the audio will be going directly to the sound device and not through DMIX, so you'll only be able to play one sound at a time.

The simplest .asoundrc file that will send audio to dmix and then to 0:7 is:

I've found that that gives me stuttering audio in Warcraft 3, so I had to add the common period_size and buffer_size parameters. The bindings section is a common performance optimization (to only care about two channels):

UPDATE:

XRUN_DEBUG is turned on, of course.

OOOOOh, I got the audio lag again (with the above setup, no Pulseaudio), and this time I had stuff in my DMESG!

Later, I noticed that on a fresh boot, dmesg would contain the the recommendation I saw earlier for a larger bdl_pos_adj value.

If I started playing Google Play Music in Chromium, then my dmesg would be spammed with the above messages.

I was able to get the messages to disappear by adding the following to /etc/modprobe.d/snd-hda-intel.conf:

(Notice that this is not the line I tried pasting in earlier from an Ubuntu ticket).

We'll see if this solves the delayed audio problem. I'm hopeful, because it gets rid of the "lost interrupt" warnings, and lost interrupts are obviously consistent with the symptoms.

Sorry, I don't own that game. Pulseaudio works for my games and any other sound output without any problems.

Hello Dugan. Hope you have been rewarded with at least some progress after all your hard work. The reason for quoting the above is that even though this may not help you on your present tack, I figure thorough and accurate data is important to a successful outcome to avoid blindly resorting to the time-wasting shotgun approach. So far it seems you have avoided such a fail. Maybe this might help keep that going.

I'm wondering where the idea above came from, or if it was ever true, what and when has it changed? I ask this because I've never worried about this issue, because as long as I can remember, it has never been an issue for me with Alsa. I don't even have pulseaudio installed but I have always been able to, for example, speak and hear on TeamSpeak 3 while at the same time hearing for example, Professor Putricide. declare "Hmmmm where did those come from?" in WOTLK. Upon a few occasions I have added XMMS2 or Aqualung, or even the typical flash players in browsers so that the raid can hear music while we hurl insults at Valanar.

I'm assuming this is what people mean by "multiple sound (sources) at the same time" and mine has always just worked. My system has 3 audio hardwares -

1] the HDMI built into my nVidia graphics card (though the audio portion of HDMI is blacklisted)

2] USB microphone section of Logitech webcam (though it still works just as well with a different Mic plugged into ======>>>>

3] Discrete semi-pro sound card ( ESI Juli@

I'm including the list in case alsa behaves differently with different hardware and notably mine has 4 discrete channels so has some onboard auto-mixing capability... however it is my understanding that essentially all sound cards have some level of internal mixing. I do use an .asoundrc but it is very basic and I can't see how it could be responsible for multi-source capability.

Hopefully this may help even if only something to check off and discard. Any other data I can provide to help if you want it, just say so. Linux is so uneven when it comes to audio in that some stuff is so advanced and/or solid and others are Rube Goldberg at best, so it's difficult to diagnose something as complex as full second delays. This can be more complicated by other Rube like devices like Flash in Browsers which is giving me fits since a Firefox "upgrade". So again, anything you need.....

probably from me or teh internet, if i understand what the topic is

by direct i meant direct
alsa by default, without an .asoundrc, resamples everything to 48kHz
if you make it be direct it will fail when a request for a sample rate or bitrate is made that is different from the one currently being played
at least on my 2 cards (i remember older ones too)

example .asoundrc
to check what the card is currently doing:
watch cat /proc/asound/card0/pcm0p/sub0/hw_params
(for card0, subdevice 0)

notice that when playing a, for example, 96kHz track without an asoundrc, it will say 48kHz

May I see your .asoundrc file, please?

I can confirm that if I use an .asoundrc file to send audio to my NVidia card (which, and this is significant, is not card 0, device 0) and I do not specify that it goes through DMix, then running two MPlayer instances at the same time will result in the second one erroring out with "sound device busy."

That is exactly why it works for you, dmix is not needed for audio-cards that have mixing capabilities in the hardware.
Many cards, especially cheap and onboard audio-cards, only have software mixing capabilities, read: Alsa has to do the mixing, hence dmix must be used.

problem is in the resampling part of mixing
mixing two inputs that have the same format is just add-ing them together with saturation

funny, i tried now playing two songs with the same format and got a "device busy"
i distinctly remember it working on my previous card (and that was a crap one)
interesting

anyway
i agree, proper hw mixing is rarely found in non-professional hardware
envy based cards being the only exception i found so far (ICE series has been continued as envy, they renamed after VIA bought them)

This thread renewed my interest in using the HDMI audio on my video card and I finally managed to get it to work, sort of, via (ugh) PulseAudio.
Sort of means it works for system notifications and playing DVDs/CD, but I haven't been able to make it work via a browser on such sites as YouTube and HBO Go.

When I tried to start PulseAudio with the rc.local file it generated this error:

Any ideas?
Thanks.

Before shutting down the computer last night I commented out the instructions in rc.local to start rc.pulseaudio and checked the ~/.asoundrc file. Maybe I was so tired I couldn't see the error, but just to be on the safe side I deleted the file and created a new one using Dugan's example (copy and paste).
This morning there were no errors on bootup and all sound is being ran through pulseaudio, including flash, widevine, etc.
I'm not too happy about using anything created by pottering (sp), but it does fix the low volume problem I've had since the .3.9.5 kernel. I don't know what is "under the hood," but it works and works well, and for the first time can I fully use the HDMI audio on the Nvidia card, AND turn the volume up enough that the monitor speakers are useful.
With the equalizer in VLC and other applications, the sound is pretty good. There is suppose to be an equalizer for pulseaudio, but I can't find a package for Slackware64 or a script on slackbuilds. If the pulseaudio equalizer is half as good as the others, the quality should get close to that of external speakers.
Thanks, Dugan.
:hattip:

One of the most-visited and referred-to (especially on other distro forums) articles on my blog is http://alien.slackbook.org/blog/addi...-sound-levels/ . You do not need Pulseaudio to crank up the sound on your computer if ALSA is having issues with your hardware. The pre-amp will compensate sufficiently in most cases.

Eric

Thank you for the suggestion, but it didn't work with this computer. I tried both of your suggested configurations and both with "hw" or "plug" and there was no pre-amp to be found in the alsamixer.
Thanks, again, for the thought.

I found out something quite important today: the two are not equivalent.

The first one overrides all of the PCM default settings in /usr/share/alsa/alsa.conf. That means that it throws away all of the plugin settings that would otherwise be there for the default PCM device (including DMix), and thus limits you to only playing one sound at a time.

The second one overrides only the settings listed, and keeps the rest at default. That means that it keeps the software mixing settings, etc. With the second one, you get the same ALSA settings that you usually get (software mixing and all): just outputting to the HDMI port.

Reference:
https://wiki.archlinux.org/index.php...e#Basic_syntax

I'm going to be trying again with the following settings, because for me it's device 7 that's listed as valid:

If I get the out-of-sync, delayed audio again, then I'm not going to try to solve it with Pulseaudio. I'm going to conclude that it's a hardware issue and give up. I'll post another update about that within a week.

UPDATE: Okay, this isn't working. If I watch a Super Mario Bros. speedrun on Youtube (which is a a good way to test for A/V sync issues), I can see the audio and video becoming less and less synchronized as time goes on. It's not as bad as I've had with other setups (it gets to be mistimed by less than a second now), and it gets better immediately if I turn off player and start it again. But if I have perfect A/V sync with my USB sound card and glitchy A/V sync over HDMI, which one am I going to choose?