[mythtv] [mythtv-commits]Ticket #1104:multi channelaudio support

[Michael T. Dean]

On 08/17/2006 01:40 AM, Mark Spieth wrote:
> yes I am using a via motherboard driver as in your list with only 6ch out
> the driver does list the order I mentioned which is why I adjusted the ac3 
> decoder to output in that order.
> looks like other cases to figure out for 8ch out cards.
>   

Both the 6ch and 8ch out cards have the same channel mapping issues.  I 
just included the 8ch assignments because it was identical to the 6ch 
but with two extra.  (I thought it was "more complete" info for you, for 
what it's worth.)  So, the 6ch mappings are affected on the cards I 
mentioned, meaning we need to figure out the 6ch mappings, too.

> I know some others are using it successfully in analog mode. perhaps they 
> would like to retest with HEAD and latest patch.
> this is what Ill do first.

I should be able to test it in about a month or so (don't have the 
hardware in place, yet, and am doing waaaay too much traveling).

In the meantime, however, if you have a chance, you may want to test 
with ALSA:surround51 as your audio output device in Myth.  Doing that, 
the ALSA default configuration for your card should map application 
output using ALSA's defaults to fit your hardware (i.e. application 
outputs are assumed ALSA defaults, driver remaps to your hardware 
defaults, so your card works like one whose hardware uses the ALSA 
defaults).  In other words, you should hear what Jan is hearing.  This 
assumes you don't have a user- or system-specific ALSA config file 
(~/.asoundrc or /etc/asound.conf) that remaps surround51 (i.e. with a 
"pcm.!surround51" definition).  You should even be able to just 
temporarily rename any ~/.asoundrc and/or /etc/asound.conf when you 
start/run mythfrontend to ensure a "clean" test environment.

If you decide to change the patch to use ALSA's defaults, you can fix 
your system by adding a ttable to the pcm definition in your ALSA config 
file you normally use.  I.e. put:

        ttable.0.0 1
        ttable.1.1 1
        ttable.2.4 1
        ttable.3.5 1
        ttable.4.2 1
        ttable.5.3 1

into the pcm definition in your user and/or system ALSA config file.  
(Feel free to send me your ALSA config if you want a more complete 
example. :)

I haven't yet come up with any acceptable solution for getting around 
the hardware-specific differences, but I feel that in the meantime, Myth 
should ensure it's outputting data using ALSA default mappings.  Doing 
so would ensure correct behavior for the largest number of cards (most 
use ALSA default mappings in hardware).  Whether that correlates to the 
largest number of Myth users, though, I couldn't even guess.  :)

I'm pretty sure that the right place to fix it is outside of Myth.  I 
have some ideas for how to do so without requiring complex 
configurations by the user, but I have to do some testing, first.  It's 
probably not that bad to put hardware-specific information in Myth, 
though, since we have a ton of it for the capture cards.  Or, we could 
just assume the ALSA defaults and let users re-map speakers within Myth 
(i.e. during configuration, Myth plays a sound and the user selects the 
appropriate speaker from a dropdown box).  I'd be interested to know 
which of these approaches the devs would prefer.

Mike