Getting sound from NVidia desktop video card to TV over HDMI
SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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.
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 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.
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
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
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)
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:
slave.pcm "ossmix" # use our new PCM here
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).
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.
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:
[*] 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:
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'll stick with these common values
I also turned on ALSA buffer overrun/underrun debugging by adding the following to /etc/rc.d/rc.local: