@Raymond Sorry for slow reply. > did you install libasound2-dev and compile chmap.c ? > gcc chmap.c -o chmap -l asound
OpenELEC (OE) is designed to do one thing - run xbmc - and the creators have stripped out much of the usual Linux environment, and block things like apt-get. I don't think there is any way to compile on OE. I am aware of the even-numbers-only channel mapping in ALSA, but thank you for pointing to a definitive reference. The upmix code you link to has no use in this discussion. As in post #8 above: Is there a way to compile chmap.c into a portable (standalone) script, that could be run on my OE machine ? Thanks again for your help. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1296017 Title: ALSA Not Selecting Correct Output Channel Map Status in “alsa-driver” package in Ubuntu: Incomplete Bug description: 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 Sample FLACs: https://db.tt/AaMpYdPJ https://db.tt/DfNjgb1t https://db.tt/n40qUvHI To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1296017/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
