I hear there’s a problem with playing satellite audio…

You may not realize it but when you run a backend such as TVHeadEnd with a satellite tuner card or device for the purpose of recording or viewing Free-To-Air signals in North America, and then use Kodi as your frontend, there’s a good chance you are not hearing the audio correctly on some channels, particularly if you have a multi-channel audio system (5.1 or better). The reason is that many of the uplinkers encode their audio in a specific manner that Kodi doesn’t understand.

This is not the same issue I wrote about in Fixing the audio on recorded programs from a certain network (which shall remain nameless), although that does show that different uplinkers encode their audio in a different ways. In fact, on “feeds” channels the audio can vary from program to program.

When you play a stream or recording in Kodi, if you display the on-screen controls or press INFO on your remote (depending on the skin you are using), you will often see an indicator of what type of audio Kodi thinks it is receiving. If you see indicators for both “Dolby Digital” and “5.1” then it is probably decoding the audio correctly. If you see anything else, such as “MP3” or “2.0”, then it may or may not be decoding the audio correctly, depending on how the source was encoded.

The strange thing is that if you have a suspect recording and you happen to have a machine that has the MythTV frontend software installed and you play the recording there, you may in fact hear the full 5.1 audio! Play the same recording using Kodi and you’ll hear audio on all channels, but your ears might tell you there’s something wrong.

Here’s the issue: 5.1 audio has 6 channels – Left Front, Right Front, Center Front, LFE (low frequency audio generally played through a subwoofer), Left Surround, and Right Surround. Kodi will play the first four of those through the proper channel in almost all cases, but it’s the Left and Right Surround channels that are mishandled. If you play the recording in the MythTV frontend, you will hear the Left Surround audio come from both the left front and left rear speakers, but with equal energy from both OR more audio from the rear. Same with the Right Surround, except that it will only come from the right front and rear speakers. However, when that same audio is played in Kodi, what sometimes happens is that any audio that should come from the Left or Right surrounds will be played at equal volume from all four Left and Right speakers, or if there is a difference in audio energy it will be biased more toward the front speakers! In other words, the Left and Right channel separation is totally lost for surround sounds.

So as you are sitting watching a recording or a live TV screen, you may notice that you are getting more than just 2-channel stereo, but it doesn’t sound quite right. Kodi will tell you it’s only 2.0 audio, and if you have a display on your receiver it may tell you the same thing. In fact it actually is 2-channel audio, viewed one way, but with the 5.1 channel information encoded within those two channels.

I’ve been reading various threads on this subject over the last few days, and it appears that in at least some cases what is happening is that the uplinkers are using Dolby Pro Logic II audio or some variation. To confuse matters further, in the audio communities this is sometimes referred to as just PLII audio.

It appears that the MythTV frontend has code that will decode this audio correctly, while Kodi does not. And you can’t even use ffmpeg to post-process a recording and convert the audio to a format that Kodi understands, because although ffmpeg has a PLII encoder, it does not have a PLII decoder.

This was a topic of recent discussion in a thread on the Kodi forum, although it appears that the developers didn’t show much interest in fixing the problem. There is a reference to a Dolby Pro Logic II test video on YouTube, which if you can figure out how to download and save, it will show you the problem in Kodi.

The thread above references a “ffmpeg user thread” – in my searching I found this archive of ffmpeg mailing list messages, and if you look at the ones with “5.1” in the subject, I suspect that is the thread being referenced, though I’m not entirely sure since the person who mentioned that thread in the Kodi forum did not include a link. In any case, reading those messages proved rather informative, even if ultimately nothing was ever resolved.

Normally when I present a problem, I like to also present a solution, but it this case it appears that for the time being there isn’t one. Programs that have this type of audio encoding will not play correctly in Kodi – it’s not that any audio will be missing, it just won’t be coming from the correct speakers, and some people may not even care about that (and if you only have two stereo speakers you definitely won’t care). If you happen to also have the MythTV frontend installed, you could play recordings in that, but in my experience some satellite recordings do not play all that well in the MythTV frontend – you may get all the audio channels coming from the correct speakers, but the audio itself may have microgaps and breakups. I suppose this in part depends on how good your HTPC hardware is; if you have a better HTPC than I do, then recordings may play fine in the MythTV frontend for you.

Most people will not want to install MythTV just to hear better audio, so that’s not really a viable solution for most readers. And MythTV has problems of its own, as I mentioned in What is the best backend software to use for a Free-To-Air satellite TV system?. So I guess the point of this article is to simply bring awareness of the problem. Maybe if enough people are aware that there is an issue, someone more knowledgeable than I will contribute code to the Kodi or ffmpeg projects that can play or convert this audio format correctly, or perhaps someone will develop a (hopefully free) standalone converter that can reformat the audio in the .ts files to something that Kodi understands.

I will note that some AV receivers may play this audio correctly IF you tell the receiver to use the correct decoder, and IF you have all the capabilities of your receiver enabled in Kodi’s System – Settings – Audio section (particularly “Dolby Digital (AC3) Capable Receiver” and “Dolby Digital Plus (E-AC3) Capable Receiver”, also be sure to “Enable Passthrough” so those settings will be used). For example, with Yamaha 5.1 receivers, you may find that using one of the Dolby or Neo:6 settings plays the audio of certain channels or recordings through the correct speakers, but selecting a “normal” mode does not. I imagine this is true of some other brand receivers as well, and may require that the receiver has HDMI connectors (this may not work if you are sending the audio to the receiver over a S/PDIF conection). I have found that the “Neo:6 Cinema” setting will play many types of encoding correctly, but feel free to try others. On such receivers, the “SUR. DECODE” button on the remote is your friend!

There is a followup article:
Why you’re not hearing full surround sound on some satellite channels – or maybe just think you aren’t


Do you run one or more TBS PCIe cards under Linux? Check your IRQs…

The other night I happened to have a ssh session open to a TVHeadEnd backend system (running Debian Linux) when this message appeared:

Message from syslogd@backend at Nov 6 23:03:02 …
kernel:[452276.219160] Disabling IRQ #16

And then the satellite card essentially stopped working – it would act like it was receiving signals, but they were all complete garbage until I rebooted the system.

It turns out that the system was putting several things on IRQ #16, as revealed by cat /proc/interrupts

 16:    1669004          0          0          0  IR-IO-APIC-fasteoi   ehci_hcd:usb1, SAA716x Core, SAA716x Core, snd_hda_intel

In searching for a solution to this, I came across this thread (and also this thread), which informed me that the TBS cards were using the old style of interrupts, and that it would be a good idea to change that so they use the newer PCI-MSI-edge type. The procedure for doing that is simple, and easily reversible if it doesn’t work.

First do this from a Linux command prompt:

lsmod | grep -i SAA716

You should see several lines containing a string such as saa716x_tbs_dvb – assuming this is the string you see, then do this:

sudo touch /etc/modprobe.d/tbs.conf
sudo echo options saa716x_tbs_dvb int_type=1 > /etc/modprobe.d/tbs.conf

If you prefer you can use a text editor such as nano to insert the single line options saa716x_tbs_dvb int_type=1 into the /etc/modprobe.d/tbs.conf file (this might be safer, since it will allow you to first verify that this file is currently empty rather than blindly overwriting it as shown above). Note that the center part of that string (saa716x_tbs_dvb) should match the string(s) you saw in the previous step.

EDIT:  As noted in cband’s comment on this article:

If you have a newer TBS card such as a TBS6905, or a mix of older and newer ones, then you need TWO lines in /etc/modprobe.d/tbs.conf:

options tbs_pcie-dvb tbs_int_type=1
options saa716x_tbs-dvb int_type=1

Next, reboot the system. When it comes back up, do cat /proc/interrupts again. You should now find the TBS cards on separate interrupts, indicated as IR-PCI-MSI-edge instead of IR-IO-APIC-fasteoi or whatever they were before. In this case…

 16:         29          0          0          0  IR-IO-APIC-fasteoi   ehci_hcd:usb3, snd_hda_intel


 46:       7973          0          0          0  IR-PCI-MSI-edge      SAA716x Core


 48:       3914          0          0          0  IR-PCI-MSI-edge      SAA716x Core

There are two TBS cards in this particular backend, which is why two interrupts are being used (and why SAA716x Core appeared twice on the IRQ 16 line prior to the change). Just FYI, you can get a more much more detailed report on what is is routed to each IRQ by running lspci -vv from the Linux command prompt, though that may be too much information for most regular users.

If it doesn’t work for any reason, just delete the /etc/modprobe.d/tbs.conf file and reboot, and you will be back to the way it was before.

My suspicion is that doing this will fix some weirdness that may very occasionally occur when using TBS cards with TVHeadEnd. Why no one tells you to do this as part of the driver installation instructions, particularly on Debian-based systems, is anyone’s guess, but if you are running TBS cards under Linux it might be worth your time to check this, assuming you want a more reliable system.

By the way, I am NOT a Linux guru by any stretch of the imagination, so please don’t ask me how any of the above Linux commands work – save those types of questions for your favorite Linux forum, please!

If you found this article useful you may also like:
A bash script to rebuild the TBS tuner drivers after Linux kernel updates

Kodi (Linux version) users, here’s a possible way to restore full 5.1 audio to certain recordings since upgrading to Gotham/Helix/Isengard/Jarvis/Krypton

If you are running Kodi under Linux and you find that certain types of recordings, including many programs recorded from satellite feeds, will play in stereo only even though you know they were transmitted with multichannel audio, here’s a possible quick fix. Bring up a terminal window and start Kodi this way:


You might also need to tweak an audio setting or two in Kodi itself. This forces Kodi to use ALSA rather than PulseAudio, as it did in the (XBMC) Frodo version and probably some earlier versions. If this fixes the problem, you can create a shortcut or a shell script that starts Kodi up this way. Apparently some distributions such as Kodibuntu already use ALSA by default, but if you are a normal Linux desktop user, chances are that Kodi is using PulseAudio on your system.

On the following AskUbuntu page…

Enabling 7.1 audio passthru in 14.04 for Kodi

… it suggests that if forcing Kodi to use ALSA works, you may want to start it using this startup script:

#! /bin/bash


It seems that this is particularly effective when the audio link between the system running Kodi and the receiver is via S/PDIF, but I’ve also observed it to help even when the link is via a HDMI connection.

There’s a discussion about this on the Reddit XBMC forum.

(Article edited August, 2015 and January, 2017 to change most mentions of XBMC to Kodi, and to add information from the AskUbuntu site).