[mythtv] OT - Keeping HDMI audio link open

Mark Perkins perkins1724 at hotmail.com
Fri Jun 24 01:04:13 UTC 2016



> -----Original Message-----
> From: mythtv-dev [mailto:mythtv-dev-bounces at mythtv.org] On Behalf Of
> Mark Perkins
> Sent: Friday, 24 June 2016 7:05 AM
> To: 'Development of MythTV' <mythtv-dev at mythtv.org>
> Subject: Re: [mythtv] OT - Keeping HDMI audio link open
> 
> 
> 
> > -----Original Message-----
> > From: mythtv-dev [mailto:mythtv-dev-bounces at mythtv.org] On Behalf Of
> > Lennart Sorensen
> > Sent: Friday, 24 June 2016 1:07 AM
> > To: Development of MythTV <mythtv-dev at mythtv.org>
> > Subject: Re: [mythtv] OT - Keeping HDMI audio link open
> >
> ...snip...
> >
> > I do wonder if those "solutions" would not cause a new problem.
> >
> > If you are running aplay, doesn't that keep the sound channel busy so
> > your other program can't play?  And even if it doesn't, what if you
> > want to
> play
> > multi channel audio, not just stereo?  How does that interact with
> something
> > that is always playing a stereo signal?
> >
> > --
> > Len Sorensen
> > _______________________________________________
> 
> The lockout was my first thought as well and seemed to be exactly the
issue
> John ran into his testing. But the more I thought about it I realised that
if I
> open up two separate firefox instances and start playing two different
> youtube clips at the same time I get sound from both simultaneously. I
also
> still get system sounds and beeps etc over the top of those. So it seems
to
> me that it shouldn't necessarily lock the sound out to other applications.
> 
> In the short reading I did I noted a comment that running aplay as root
rather
> than user could lockout the sound. But.... not sure I haven't tested it.
Maybe
> the ampersand (&) on the end of the aplay command does more than I
> thought it did. Sorry to say not my area of expertise so I may be giving
more
> questions and misdirection than answers.
> 
> If I get time later I might give it a try and see what happens. It should
be easy
> enough to do.
> _______________________________________________

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.




More information about the mythtv-dev mailing list