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

[Ed W]

On 04/04/2010 11:29, Jean-Yves Avenard wrote:
>> 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
>>      
> It all depends at what the audio software/hardware interface expect. I
> know what it is with ALSA, AC3 and DTS. But JACK ? I don't :P
>    

OK, from looking around I *believe* the summary of channel ordering is:

Linux:
- Alsa = LRLrRrCLfe
- OSS = SMPTE, ie LRCLfeLrRr ( 
http://manuals.opensound.com/developer/SNDCTL_DSP_GET_CHNORDER.html )
- Jack = whatever the output device uses.  Most commonly Alsa. Suggest 
standardise on that and let the user map channels if they wish
- Pulse audio = unknown
- AC3 encoder = unknown (presumed SMPTE?)

Osx
- Coreaudio = SMPTE

Windows
- Not checked, but believed to be most commonly SMPTE on windows?


>> 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?
>>      
> I disagree there...
> Each software audio interface have their own order ; SMPTE is what
> mythtv now works with.
>    

I don't see how your argument addresses the suggestion though?

The goal should always be to abstract repetition and redundancy and we 
now have two output layers repeating the same re-ordering?  My first 
thought it to have the output layer set a property to indicate it's 
preferred multi-channel output ordering and then the samples can be fed 
in the correct order.  This allows us to optimise in only one function also

At the very least we should move the function to some shared .h file?

It's only a small function though I agree.  I'm just a neatness junkie.  
Also I wasn't sure how far the re-ordering was required?


Note, have a look at the latest mplayer - it's tidied up the audio layer 
quite a lot and I think the code is worth copying.  They have abstracted 
out the ring buffer in the latest code for example and this tides up a 
lot of code.

Anyway, I will hack around with a new output layer and send over a patch 
once I have something working better - if you don't mind adding the 
channel re-ordering in the current Jack output layer then this will at 
least give people using stable 0.23 something to play with though, so 
yes please to that.

Thanks

Ed W