ALSA Not Selecting Correct Output Channel Map

Hi All
As preface to this question, please know that I'm a complete noob with Linux - forgive my lack of understanding the basics, and any dumb questions that may give rise to.

The issue - possible ALSA driver bug - is experienced when running xbmc, via OpenELEC. Playback of multichannel FLAC files is failing with 4.0-CH surround music (ie: Quadraphonic). PB fails inasmuch as xbmc sends the audio (MCH-PCM > HDMI > AVR) in a format incompatible with the AVR.

After much dialogue with the relevant xbmc devs, I've been told this is a driver problem (ALSA), and to report it here at Launchpad.
(FYI: discussion begins here -> http://forum.xbmc.org/showthread.php?tid=170338&pid=1638835#pid1638835, see posts by "gjwAudio" )

What Happens:
4.0 audio is output over HDMI as FL,FR,BL,BR, but my AVR does not recognize this format, and defaults to 2-CH (stereo) - no back channel information.

What Should Happen:
4.0 audio should be sent as 5.1 PCM, with appropriate "extra" channels muted.

Hypothesis:
ALSA is not flagging 4.0 channel map as invalid for this receiver (based on audio-related EDID info), and xbmc configures 1:1 output mapping (FL,FR,BL,BR > FL,FR,BL,BR).

Testing in OpenELEC:
Three FLAC sample files were used: 3.0, 4.0 and 5.1 channels. xbmc configured both 3.0 & 5.1 files as 5.1 PCM, and played correctly through the AVR. The 4.0 file was configured 1:1, and the back channels failed to play.

When setting xbmc for global fixed output of 5.1 channels, all three files played correctly - however, this fixed setting also locks the sample rate, and forces unnecessary re-sampling, depending on the particular song being played. It also prevents legitimate upmixing of 2.0 video soundtracks to "surround".

The xbmc devs explain the behaviour thus:
( http://forum.xbmc.org/showthread.php?tid=170338&pid=1651346#pid1651346 )
"This happens when opening 3.0 (FL,FR,FC)
  - you can't have gaps, and in ALSA map, FC is at pos 5 (FL,FR,BL,BR,FC)
  - only even numbers of channels are allowed

This is why 3.0 opens as 5.1.

4.0 as FL,FR,BL,BR is valid, and most devices don't have issues with this. We can't just open 5.1 for this case. "

  --and-- (regarding the new audio engine "ActiveAE")
( http://forum.xbmc.org/showthread.php?tid=170338&pid=1651708#pid1651708 )
"ActiveAE plays no role in this scenario. It is the ALSA sink and the driver. The driver should not open in 4.0 mode if the device does not support it. This needs to be fixed in the driver. Others will complain if we opened 4.0 as 5.1 because this would disable upmixing in the AVR. "

  --and--
( http://forum.xbmc.org/showthread.php?tid=170338&pid=1655015#pid1655015 )
"If you don't have configured fixed mode, XBMC tries to open the channels layout with best match to the input stream. In case this is FL,FR,BL,BR - which also matches ALSA channel map, we try to open this layout. If the audio device does not support this format, ALSA should fail opening. Then we try the next layout which would be 5.1 in this case."

  --and--
( http://forum.xbmc.org/showthread.php?tid=170338&pid=1655895#pid1655895 )
"If ALSA opens that mask, then that's a driver problem and should be reported upstream to the ALSA devs."

Testing in Windows:
As another check on the xbmc audio output logic, I was asked to run the same FLACs through a Windows install (same beta release version of xbmc).

All files played correctly under Windows. Please note the "5.1 PCM" indicator lit up on the AVR, for every file. This suggests the correct EDID info was available to xbmc through the Windows driver(s).

Linux Setup:
OpenELEC v4.0 beta 2 (Gotham) - Generic x86_64; Intel 847 Celeron NUC, KVR1333D3S9/4G RAM, Kingston SMS200S3/30G mSATA > 2m HDMI > Anthem Statement D2 (AVR) > Samsung PN51E6500.

Windows Setup:
xbmc v13.0 beta2 (Gotham), Asus X502C - i3-3217U, 4 GB RAM, Intel HD 4000 graphics, Win 8.1 > 2m HDMI > Anthem Statement D2 (AVR) > Samsung PN51E6500.

It is useful to know, the same fault occurs under OpenELEC stable build v3.x.

I hope this is enough information to begin looking into why the EDID info is not getting through to the xbmc software.

Thanks in advance for your help and consideration.
Grant