Slackware 14.2 + Intel NUC + HDMI = slow video/audio
 

I have a very weird problem with Slackware 14.2 and 6 Intel NUC i3 boxes. Video/sound seems to be playing at half speed when sound is going over HDMI.

Switching to analog output (using pavucontrol), everything works.

I can't switch to analog sound, as all the NUC boxes are connected to Dell monitors with zero analog input.

I currently have 22 Slackware desktops deployed in my company. 16 of these are Lenovo laptops and 6 are Intel NUC i3 boxes. The Lenovo laptops works as intended. All 6 Intel NUC boxes exhibit this odd behavior.

Any and all suggestions are more than welcome.

What happens if you output directly to alsa and bypass pulseaudio?

Basically, the processing power required for your wanted HDMI link is beyond of that one given by that little little crap called by its mom, out of love, "Intel NUC i3".

After all, what you expect from a little crap driven by a processor with TDP of 15W? ;)

Some things which could concur to:

You use a 1920x1080 video resolution and a 5.1 Audio link, like a boss, while you are on Mesa's software rendering mode, which already make your... so called processor, very busy.

Finally, I strongly suggest you to use some real computers and dump those little craps, or use them as glorified routers...

PS. You know that those NUCs are supposed to be used as small HTPCs at home, not on a Corporate Environment, right? How the hell arrived them on your company?

If they're designed to be used as HTPCs, most HTPCs are connected to a 1080p tv and at least a 5.1 surround system, so why are these underpowered for doing the exact same thing (playing video)? Why is it bad to have a NUC in a corporate environment? If the machine fits the requirements and is covered by the manufacturer (required at my job -- once the warranties expire, the machines are replaced), then there shouldn't be any issues using them.

@OP, Intel products have been highly problematic in regards to proper graphic support in Slackware. There have been many threads and many drivers tried on the forum, both during the development of 14.2 and after it was released. It seems when the Intel developers fix issues for one chip, they introduce issues in another. It might be worth getting the latest Intel driver for X and compile it to see if it helps your issue. Pat tried to find the driver that worked the best, but it's likely that the driver won't work great for everyone.

Also, please post the output of your /var/log/Xorg.0.log so we can see how the driver is being used. Some of the Intel gurus here might have suggestions for an xorg configuration file (to override any possibly problematic defaults).

Finally, what are you using to play videos and what type out video output are you using (in mplayer, it's specified using the -vo option). Have you checked to see if the CPU is pegged while playing videos? If so, this indicates it isn't offloading to the GPU to be decoded. If I remember right, Intel doesn't properly support vdpau (video hardware accelerated playback -- using the graphics card to process your videos so the CPU doesn't have to do it), which is included in Slackware and instead supports VAAPI, which many video players don't support. To enable vdpau support for Intel chips, you need libvdpau-va-gl. Note: according to SBo, it does require ffmpeg (and ffmpeg has a lot of possible dependencies) and you will either need to source the added file in /etc/profile.d/ (source /etc/profile.d/vdpau-va-gl.sh) or log out and log back in for the correct video settings to take effect.

Not that it really matters, but here you go: They are being used to run a single browser in xmonad, that does nothing but handle a ticketing system in one tab and a chat/webmail client in another tab. Processing power is not an issue. Most of the time xmobar reports around 5% cpu usage.

We need functional sound because some of the tickets contain links to wav files hosted on Google Drive. These play at half speed when sound output is via HDMI, and at normal speed when sound output is analog.

This prompted me to test a few random videos on youtube, where the same thing happened: Sound over HDMI resulted in slow sound and slow video playback. Sound over analog resulted in completely normal playback of both sound and video.

In none of the cases do the CPU spike. This does not seem to be related to lack of processing power, as it works just fine with Ubuntu 15.04.

How do I do that? I have very little knowledge of the intricacies of Linux sound. :D

Xorg log here: https://gist.github.com/ThomasLocke/...2ec61280122cae

I tested video playback in Aliens latest Chromium. CPU did not spike. Also note that as soon as I switch sound output to analog, both the sound and the video play a regular speed.

I don't need video playback at all - all I need is to be able to play a few wav files here and there. I know for sure that these small boxes can do that, as I have one running Ubuntu 15.04 that works just fine. :)

Depends what you're using to play the media file.

aplay -L will list the alsa device names you can specify.

If your HDMI card is listed as 'hdmi' (they usually are) then to output to the alsa device you can then do something like:
aplay -D hdmi soundfile.wav

However, it's often a good idea to use the 'plug' plugin to do rate conversion as sometimes you will get incompatible sample rates and may get a failure to open the output device without it (an alsa device can only work at one rate at a time), so the following would be more reliable:
aplay -D plug:hdmi soundfile.wav

mplayer uses a slightly different syntax (it's documented on the man-page):
mplayer -ao alsa,device=hdmi soundfile,wav

Note: if you play a 44,100 samplerate file at 22,050 without rate conversion then it will play twice as slow as it should, though in theory that shouldn't happen as the underlying alsa devices can't be opened using two different sample rates at the same time and the player program should never try and do that.

Finally, you might want to do a pulseaudio --kill before attempting any of the above as pulse may have grabbed the output device and could potentially keep it open.


Linux sound is a mess: very few people understand it properly, and IMO pulseaudio only made matters worse.

No truer statement could be said about pulseaudio. It's the abortion that crawled from the trashcan and somehow survived.

When I have parties at the house now, I have to boot back to my 14.1 Slackware hdd to be able to use the alsa audio on it and have good sound for music for the evening (I've got some pretty nice logitech 5.1 speaker setup, 641 IIRR, and my *old* Live! soundcard, and this setup can literally shake the house. On the 14.2 sdd the pulseaudio is bland, gutless and has no controls for treble, bass, etc, etc and is just barely usable for watching dvd's/movies).

FWIW, on my HTPC hooked up to a nice Dolby Atmos capable Onkyo receiver (via HDMI), I didn't notice any difference is audio quality from 14.1 to 14.2. Both can equally shake the house. Both installs were pretty much straight stock except for kodi and its dependencies.

Maybe my ears aren't as attuned as some (although, I feel I do have an ear for audio quality) or maybe pulseaudio quality varies depending on the hardware. Honestly, I don't know. As far as my htpc is concerned, had I not known that pulse was added to Slackware, I would've never found out based on sound output.

Then how about you to skin the cat, completing your Redneck-style, err... Corporate Computers with a pair of Chinese audio cases, those sell for $5? You know, those little craps powered from USB?

I bet that they will even sound better than the usual integrated speakers from a monitor, then you have a very nice reason to popup with them at Office... ;)

It is a bit unfair to compare that Ubuntu, shipping those shameful old package versions, starting from kernels and anything else, with the glorious Slackware releases, which are so modern that even Arch Linux does not dare to challenge them... :hattip:

What do we have in a Slackware release that is more modern than what Arch has? Keep in mind, -current is not a release... it is a development version that Pat has kindly made available to the public. If you're stupid brave enough to be running -current in a production environment, then that is on you.

Pat is continuously trying to keep Slackware relevant, and to do that, you need to upgrade packages included within the OS.

Hi,

You seem to be using UXA.
Can you try switching to SNA?

--
Best regards,
Andrzej Telszewski

Done. Sadly it makes no difference.