[mythtv] Channel ordering wrong in 5.1 (at least for me)

Ed W lists at wildgooses.com
Sun Apr 4 09:30:43 UTC 2010


Hi

>> Using Jack as my output driver I believe I am seeing channel ordering from
>> Myth as:
>>     "lf", "rf", "center", "lfe", "lr", "rr"
>>     (lr = left rear, rf = right front, etc)
>>
>> What I am expecting is (This is the ordering used by default out of
>> mplayer/xine):
>>     "lf", "rf", "lr", "rr", "center", "lfe"
>>      
> mplayer channel order is straight of ffmpeg ... you can then change
> the order using the configuration file.
>    

Sure - for the last few years I have used mplayer without any remapping 
configuration.  Also at least when I last looked at the mplayer audio 
code (some years now) there was no remapping of channels in any of the 
lower audio levels? (Could have been some in the decoders, don't recall 
really)

> Channel ordering is defined by what ffmpeg output
>    

Understood - I don't know what ffmpeg outputs, but at least in the past 
I have reason to believe it was the "linux" order?

> Since mythtv 0.22 and the version of ffmpeg use then; the channel
> order is always shown to the audio interface as SMPTE.
>    

OK, understood.  I just checked the alsa code and I see: 
"ReorderSmpteToAlsa6ch"

OK, so my understanding is that on linux at least (possibly everything 
except windows in fact), the channel ordering for analogue output should 
always be the "re-ordered" version?  I would need to look at the code 
for the spdif encoder (presumably you already know?) but wouldn't be 
surprised to find that it also wants the re-ordered channels?

With that in mind can I suggest that the reordering function be moved to 
the base class so that we don't re-implement it everywhere?

Also if you happen to know which interfaces need which ordering (and 
which are unknown) then it would be interesting to document that, 
perhaps we can stick it as a note in the relevant code?

> I didn't touch the JACK code ; because I don't use JACK (no sure why
> anyone would use JACK to be honnest)
>    

Sure, I will clear the jack interface up - no probs.

As to why you would use Jack, well it's a "plug" library that sits 
between the application and your alsa output (or whatever).  So 
basically it's only useful for situations where you have a need to plug 
something in to hack around with the audio before it hits the sound 
card.  To a large extent you can already do a bunch of monkeying around 
using only Alsa, so it's going to be fairly specialist almost by 
definition....  I think the two main uses will be:

- Network jack. Something like what you can do with Pulse where you can 
push the audio to a different machine (with very controlled latency) 
over tcp. Allows for some funky multi-room stuff

- Specialist audio filters.  eg I use Brutefir which allows me to apply 
very long FIR filters to the audio in near realtime. It takes a bunch of 
very clever maths, but basically I can measure the parameters of my 
audio system and then apply a correction to fix some of the measured 
deficiencies.  This allows you to get a very high quality audio system 
and for example apply speaker crossovers digitally.  I use DRC to help 
me calculate global system corrections, this is then output directly to 
a bunch of power amplifiers which are hooked up to a bunch of big speakers


> If it's broken now; it has pretty much always been broken or got
> broken following the ffmpeg resync
>    

Sure - 5.1 has never worked, this isn't new.  It's just that now that 
the 5.1 output is starting to look very solid I thought I would try and 
get this working. (If you look at the svn logs you should see that I 
have contributed to the audio layer intermittently over the last 6 odd 
years)


Great if we can tidy this up a bit and try to get it as solid as 
possible?  For example I'm wondering if we can't move the re-ordering 
into the point where we feed in new samples to the output layer? The 
driver could indicate the format it desires and the base class could do 
all the re-ordering?  What do you think?

Cheers

Ed W




More information about the mythtv-dev mailing list