[mythtv-users] Raspberry Pi - Audio Passthrough

[rob e]

hmmm ... me too

I have additional information fwiw

I set omxplayer up as the "alternate player" for videos and it plays 
videos flawlessly
Kodi, running on the same OS image also plays videos and AC3 TV flawlessly
Alsa will produce corrupted sound ... but the video framerate is NOT 
impacted
At no time did CPU or memory usage appear to be unreasonable, it's 
mostly very low

I've tried nearly all combinations of Alsa, OpenMax for sound and Alsa, 
OpenMax and Software for mixers (along with no mixer). Nothing seems to 
resolve the issue - you can either have sound or video, not both :(

Odd that it seems specific to Myth while omxplayer and Kodi all play the 
same files perfectly

I have a set of scripts to invoke omxplayer from the myth interface if 
that helps - setting it up was a project in its own right :)
To use omxplayer you need to resolve (a) how to invoke omxplayer passing 
the correct filename (b) how to control omxplayer since there isn't a 
keyboard interface in this mode, nor is there a lirc interface - you 
need to use lirc to drive the dbus interface

Based on these
- https://www.raspberrypi.org/forums/viewtopic.php?t=98247&p=682147
- 
https://raw.githubusercontent.com/popcornmix/omxplayer/master/dbuscontrol.sh

Edited the above dbuscontrol scrip a bit (add facility for building 
user-id into the dbus channel and add a new case clause for seekback 
since irexec would not pass a negative number)
# ================ RE Changes Start ================ #
# 2 original lines commented out refer here
# https://www.raspberrypi.org/forums/viewtopic.php?t=98247&p=682147
#OMXPLAYER_DBUS_ADDR="/tmp/omxplayerdbus.${USER:-root}"
#OMXPLAYER_DBUS_PID="/tmp/omxplayerdbus.${USER:-root}.pid"
if [ -f /tmp/omxplayerdbus.$USER ]
then
    OMXPLAYER_DBUS_ADDR="/tmp/omxplayerdbus.$USER"
    OMXPLAYER_DBUS_PID="/tmp/omxplayerdbus.$USER.pid"
else
    OMXPLAYER_DBUS_ADDR="/tmp/omxplayerdbus"
    OMXPLAYER_DBUS_PID="/tmp/omxplayerdbus.pid"
fi
# ================ RE Changes End ================ #
# ================ RE Changes Start ================ #
# Added this clause after "seek)" to overcome IRexec not sending 
negative numbers
seekback)
     SKIP_BACK=$(( $2 * -1 ))
     dbus-send --print-reply=literal --session 
--dest=org.mpris.MediaPlayer2.omxplayer /org/mpris/MediaPlayer2 
org.mpris.MediaPlayer2.Player.Seek int64:$SKIP_BACK >/dev/null
     ;;
# ================ RE Changes End ================ #


I wound up adding lines of this form to the lircrc (my remote is a Dvico 
usb). Note the use of a hard coded user id for "su", if someone can 
advise a way to soft code this I'd be grateful
begin
     remote = DVICO_MCE2
     prog = irexec
     button = down
     config = su -l pi /usr/local/bin/omxplayer_dbuscontrol.sh seek 
600000000
     repeat = 0
     delay = 0
end

Other lircrc parameters
     button = ok
     config = su -l pi /usr/local/bin/omxplayer_dbuscontrol.sh pause

# 10 minute seek ~ 600000000, 1 minute ~ 60000000, 30 seconds ~ 30000000
     button = up
     config = su -l pi /usr/local/bin/omxplayer_dbuscontrol.sh seekback 
600000000

     button = down
     config = su -l pi /usr/local/bin/omxplayer_dbuscontrol.sh seek 
600000000

     button = left
     config = su -l pi /usr/local/bin/omxplayer_dbuscontrol.sh seekback 
30000000

     button = right
     config = su -l pi /usr/local/bin/omxplayer_dbuscontrol.sh seek 60000000

     button = vol_up
     config = su -l pi /usr/local/bin/omxplayer_dbuscontrol.sh volumeup

     button = vol_down
     config = su -l pi /usr/local/bin/omxplayer_dbuscontrol.sh volumedown

     button = back
     config = su -l pi /usr/local/bin/omxplayer_dbuscontrol.sh stop

     button = playpause
     config = su -l pi /usr/local/bin/omxplayer_dbuscontrol.sh pause

     button = stop
     config = su -l pi /usr/local/bin/omxplayer_dbuscontrol.sh stop



Created this script to call an external player, since I wanted to use a 
server defined Storage directory
#!/bin/bash
# Decode a Mythtv video string into a file name
# I set this as the "alternate" player in /setup/media settings/videos 
settings/player settings
#    Set fully qualified name then add %s to cause video name to be passed
#
MYTH='myth://Videos@my-servername/'
LOC_DIR='/mnt/dvd_rips/dvds/'
# Mythtv passes name of video here
VIDEO=$1
# Strip myth protocol and server details off the video name
LOC_FILE=${VIDEO#$MYTH}
# omxplayer options http://hackersome.com/p/popcornmix/omxplayer
#   -o = output for audio, in my case set to hdmi
#   -b = set screen background to "blank"
#    --display = set which display to draw on ... unused
OMX_CMD="/usr/bin/omxplayer -o hdmi -b "
# Start video from NFS linked directory (must be same as myth server 
knows as Storage directory)
$OMX_CMD "$LOC_DIR$LOC_FILE"

-------------------------------------------------------
Additional detail on Mythfrontend sound testing conducted

Additional detail
1) If I use ALSA, pointing to either the hw:CARD=ALSA,DEV=0   or Dev=1 
(or the plughw versions for that matter) then
         a) If speakers =  Stereo and no AC3 or DTS then sound plays ok
         b) If speakers = 5.1  with AC3 and DTS  set then recordings 
with stereo sound play ok but recordings with AC3 or DTS do not (play 
jittery noise)
         c) all vob & mkv & avi files with AC3 or DTS play the video 
component without trouble, unlike OpenMax - see below (even tho sound is 
corrupted as noted above)
2) If I use OpenMax:HDMI (with OpenMax mixer / volume control, or no 
mixer) then
         a) Speakers = stereo then sound plays ok and AC3 from TV signal 
plays ok, but no AC3 or DTS at the receiver (obviously)
         b) Speakers = 5.1 with AC3 and DTS then AC3 sound in videos 
causes lots of fast / slow / fast / slow in the video
         c) Speakers = 5.1 with AC3 and DTS then DTS sound in MKVs ie. 
video (as opposed to sourced from TV) is even worse than AC3 to the 
point where it's unwatchable
3) If I use OpenMax:HDMI (with Software mixer / volume control) then
         a) Speakers = stereo then sound plays ok and AC3 from TV signal 
plays ok, but no AC3 or DTS passed through (obviously)
         b) Speakers = 5.1 with AC3 and DTS then AC3 and DTS sound is 
badly distorted ... sounds very jittery
         c) Video stream seems to play fine in all cases even though 
sound is corrupted
4) If I define OMXPLAYER an alternate player for video and initiate that 
via the Mythfrontend "alternate player" option then
         a) AC3 and DTS files play without any trouble ie. both audio 
and video play well in TV and "video" content
5) Kodi is installed on the same OS image and it works perfectly for all 
content, both video and audio play without trouble when Passthrough = 
true including AC3 and DTS

It seems odd that omxplayer and Kodi can successfully use OpenMax to 
pass 5.1 digital sound without impacting video, but Myth cannot. Also 
seems odd that I can't get Alsa to pass 5.1 digital sound through, and 
that video plays smoothly using Alsa but not OpenMax when sound is 5.1.

The Pi MPEG and VC1 licences are installed and working ok

The system doesn't have anything in /etc/asoundrc,
~/.asoundrc is as follows ............
pcm.!default {
         type hw
         card 0
         device 1
}
ctl.!default {
         type hw
         card 0
}


I have set the following in Config.txt
# Customisations to config.txt
# Framebuffer needed to obtain 1080P screen
framebuffer_width=1920
framebuffer_height=1080
hdmi_drive=2
## Force HDMI 1080P even when cable not connected
sdtv_mode=2
hdmi_group=1
hdmi_mode=16
# ----
decode_MPG2=0x
decode_WVC1=0x
# Use my previously defined edid file at /boot/edid.dat
hdmi_edid_file=1
# Force passthru of AC3 and DTS even when not reported in EDID
hdmi_force_edid_audio=1
# This is supposed to enable bitstreaming over HDMI ie. un-altered data out
no_hdmi_resample=1
hdmi_stream_channels=1
# End Customisations

I tried using iecset to configure "audio off" but that didn't seem to 
work. Furthermore, when I do change these settings, they seem to revert 
as soon as Myth plays content. Below is the iecset output
Mode: consumer
Data: audio
Rate: 44100 Hz
Copyright: protected
Emphasis: none
Category: general
Original: 1st generation
Clock: 1000 ppm

I also tried sending AES bits to Alsa but they were rejected even when 
using aplay or speaker-test