[mythtv] OT - Keeping HDMI audio link open

[Mark Perkins]

> Ok, I have done a bit of mucking around and found the following:
> 
> It appears that using aplay -D plughw:xxxxxx will prevent automatic dmix
> (which is essentially what you need to play concurrent streams). Hence why
> the aplay command James used in the other thread locked the audio away
> from MythTV (and did the same for me in my testing generating the
identical
> device unavailable message when MythTV tried to play something back).
> 
> So a lot of the threads (like
> http://ptspts.blogspot.com.au/2009/03/how-to-select-alsa-sound-card-and-
> have
> .html) talk about getting the environment variables correct so that
> commands like "aplay /some/sound/file.wav" play to the correct output by
> default without the -D switch, which should allow automatic dmix. However
> my system apparently doesn't have the environment variables correct as I
> couldn't get it to work with my initial attempts (although I am interested
now
> so will keep trying).
> 
> What did **sort of** work for me was changing the audio setup in
> mythfrontend to point to the dmix device ALSA:dmix:CARD=NVidia,DEV=7
> rather than ALSA:hdmi:CARD=NVIDIA,DEV=1 (which I think John had already
> done). Btw
> DEV=7 in the first one and DEV=1 in the second is not a typo although I
don't
> know why they would be different. I then used this command to play the
> silence:
> 
> aplay -D dmix:CARD=NVidia,DEV=7 -c2 -r48000 -fS32_LE < /dev/zero
> 
> HOWEVER - the dmix output option appeared to be very very fussy about
> the format of what was sent to it so I still couldn't get aplay
> /some/sound/file.wav to work as it complained about the format (and I
> suspect why John got errors like aplay: set_params:1239: Channels count
not
> available). It also meant I lost all surround sound options in MythTV. But
it did
> get the two running at the same time. Whether it would be enough to stop
> an amp from going to sleep I can't test because mine doesn't go to sleep.
I do
> believe it did make a definite improvement in the speed with which audio
> started playing at the start of a recording, but again I have not had a
particular
> issue in the past so the difference for me might have been 0.25 - 0.5
seconds
> of audio. But it did make a difference.
> 
> 
> _______________________________________________


Ok. By following this -
http://superuser.com/questions/626606/how-to-make-alsa-pick-a-preferred-soun
d-device-automatically I have managed to get alsa to default to the correct
device. I did:

cat /proc/asound/modules

That showed I had 2 x "snd_hda_intel" and 1 x "snd_usb_intel" so to tell
them apart I did:

cat /proc/asound/cards

That showed me which card was my NVidia card (it was listed second). I then
edited (as root) /etc/modprobe.d/alsa-base.conf and added to the very bottom
of the file:

options snd_hda_intel enable=1 index=0
options snd_hda_intel enable=0 index=1

And then rebooted. On reboot running the command:

aplay /some/audio/file.wav

correctly outputs audio over my amp without the need for the -D switch. I
then ran the following command in a terminal window:

aplay -c2 -r48000 -fS16_LE < /dev/zero

and just left it running. I then started mythfrontend and played a recording
and it played fine. Seemed perfect. However - two caveats. Firstly I did
some testing by constantly looping a wav file instead of playing /dev/zero
and found that it is still NOT mixing the two together. The aplay command in
the terminal window actually appears to be "paused" once mythfrontend starts
playing and it resumes once mythfrontend stops playing a recording.
Nonetheless, at this point I would be hopefully that this arrangement would
stop the amp going to sleep (but I can't test as my amp doesn't go to
sleep). Secondly, I did not really notice any reduction in the time taken
for audio to start playing (I currently have about 1.5 sec of video before I
hear any audio having also put my amp into direct play mode). My initial
guess was because the aplay command is not using the same audio codec as the
recording so the amp still needs to change over. I tried:

aplay -c2 -r48000 -fMPEG < /dev/zero

but my card would not support MPEG directly so the command failed. Your
mileage may vary.

I tried replacing aplay with mpg123 and that would successfully play mpeg
files, but did not improve the starting audio lag. I actually even went as
far as using ffmpeg to extract the audio from the recording and played that
as it is clearly exactly the correct format to make sure the amp is dialled
in but even that made no further improvement to the starting audio lag. Not
sure where to go from here on that part. Skipping back once in mythfrontend
does get the audio to play that initial 1.5sec so I think the concept is
sound, it's a matter of getting the implementation correct.