[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