Getting sound from NVidia desktop video card to TV over HDMI

ReaperX7 · 06-27-2014, 07:48 PM

Quote:

Originally Posted by NGIB

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...

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.

dugan · 06-27-2014, 09:18 PM

Quote:

Originally Posted by genss

.asoundrc in HOME

Code:

pcm.!default {
  type hw
  card 1
  device 3
}

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.

dugan · 06-28-2014, 04:11 AM

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.

Alien Bob · 06-28-2014, 05:12 AM

Quote:

Originally Posted by dugan

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.

Nice to have added to the Slackware wiki perhaps?

Eric

dugan · 07-03-2014, 03:58 AM

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:

Code:

pcm.!default {
  type hw
  card 1
  device 3
}

ctl.!default {
  type hw
  card 1
  device 3
}

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.

dugan · 07-04-2014, 01:23 AM

I think I solved it.

Code:

pcm.ossmix {
    type dmix
    ipc_key 1024
    slave {
        pcm "hw:1,3"
        period_size 512
        buffer_size 4096
    }
}

pcm.dsp0 {
    type plug
    slave.pcm "ossmix"
}

pcm.default pcm.dsp0

ctl.mixer0 {
    type hw
    card 1
    device 3
}

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.

dugan · 07-05-2014, 05:33 PM

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:

Code:

pcm.ossmix {
	type dmix
	ipc_key 1024
	slave {
		pcm "hw:1,3"
		period_size 1024
		buffer_size 8192
	}
	bindings {
		0 0
		1 1
	}
}

pcm.dsp0 {
	type plug
	slave.pcm "ossmix"
}

ctl.mixer0 {
	type hw
	card 1
	device 3
}

pcm.default pcm.dsp0

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.

genss · 07-05-2014, 06:28 PM

i don't have hdmi
try making a file /lib/modprobe.d/alsa.conf containing

Code:

options snd slots=,nvidia-sound-module-name

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

Code:

blacklist snd-hda-intel

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

dugan · 07-05-2014, 08:03 PM

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

dugan · 07-06-2014, 05:19 PM

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:

Code:

pcm.ossmix {
	type dmix
	ipc_key 1024
	slave {
		pcm "hw:1,3"
		period_time 0
		period_size 512
		buffer_time 0
		buffer_size 8192
		rate 48000
	}
	bindings {
		0 0
		1 1
	}
}

pcm.dsp0 {
	type plug
	slave.pcm "ossmix" # use our new PCM here
}

ctl.mixer0 {
	type hw
	card 1
	device 3
}

pcm.default pcm.dsp0

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).

ReaperX7 · 07-06-2014, 06:38 PM

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

dugan · 07-06-2014, 09:07 PM

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.

Code:

pcm.dmixed {
	type dmix
	ipc_key 1024
	slave {
		pcm "hw:1,3"
		period_time 0
		period_size 512
		buffer_time 0
		buffer_size 4096
	}
	bindings {
		0 0
		1 1
	}
}


pcm.dsnooped {
	ipc_key 2048
	type dsnoop
	slave {
		pcm "hw:0,0"
		channels 2
	}
}

pcm.asymed {
	type asym
	playback.pcm "dmixed"
	capture.pcm "dsnooped"
}

pcm.dsp0 {
	type plug
	slave.pcm "asymed"
}

ctl.mixer0 {
	type hw
	card 1
	device 3
}

pcm.default pcm.dsp0

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.

dugan · 07-07-2014, 02:15 AM

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

Code:

options snd-hda-intel enable_msi=1 bdl_pos_adj=-1,64

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.

dugan · 07-07-2014, 12:46 PM

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.

dugan · 07-08-2014, 11:56 PM

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:

Code:

[*] Debug
[*]     More verbose debug
[*]     Enable PCM ring buffer overrun/underrun 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

Code:

grep valid eld*

got me:

Code:

eld#0.0:eld_valid		0
eld#0.1:eld_valid		1
eld#0.2:eld_valid		0
eld#0.3:eld_valid		0

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:

Code:

pcm.dmixed {
	type dmix
	ipc_key 1024
	slave {
		pcm "hw:1,7"

		period_time 0
		buffer_time 0

		# I'll stick with these common values
		period_size 1024 
		buffer_size 8192
	}
	bindings {
		0 0
		1 1
	}
}


pcm.dsnooped {
	ipc_key 2048
	type dsnoop
	slave {
		pcm "hw:0,0"
	}
}

pcm.asymed {
	type asym
	playback.pcm "dmixed"
	capture.pcm "dsnooped"
}

pcm.dsp0 {
	type plug
	slave.pcm "asymed"
}

ctl.mixer0 {
	type hw
	card 1
	device 7
}

pcm.default pcm.dsp0

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

Code:

echo 1 > /proc/asound/card1/pcm3p/xrun_debug
echo 1 > /proc/asound/card1/pcm7p/xrun_debug
echo 1 > /proc/asound/card1/pcm8p/xrun_debug
echo 1 > /proc/asound/card1/pcm9p/xrun_debug

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.