@sam_nazarko, seriously… I offered my help regarding the testing of other file formats, but didn’t even get so much as a reply to that. If people are not responding, why not fall back on users who want to help. I’m pretty, sure the later channel map issue is also present in my setup, but I just didn’t notice it in the first test runs as I didn’t use AAC e.g. Why not use the resources people are offering?
1 Like
It seems that the issue reported by most users affected after changing the channel map involved hearing no audio at all, and when using SPDIF. If this applies to you, then I’d recommend re-applying the channel map fix and posting some logs (we can pick it up by PM)
I didn’t realise that you were experiencing a loss of audio / using SPDIF.
Sam
Sam, I think what he’s saying (and what I’ve been saying) is that the two of us have been very vocal about our willingness to test. If other users reporting issues aren’t giving you the same courtesy, why prioritize them over us? I realize you’ve provided a workaround for us, but we both obviously want to know that this is fixed for good.
1 Like
For what’s worth; October release works fine for me with the shipped alsa config 
I got nothing to complain about at all thus my radio-silence, happy user (wify too! 
)
We reverted things (quite promptly) when things were reported as non-functional. However the former channel mapping isn’t ideal for long term.
Thanks. You guys are already testing and it’s working. So I need it to be tested and reported on by those whom it doesn’t work for.
Further, you said today that you were unwilling to try updates, and when I reminded you that they are indeed optional, you remarked:
thanks for clarifying that I have free will and don’t have to install your updates.
While I can understand ‘if it ain’t broke’ users unfortunately would need to be running the latest version of OSMC for these tests to be meaningful.
The fix you have applied manually won’t be reverted by any update.
When improvements are made, I will run it by everyone in this post before it’s pushed. We won’t push an updated version until users that have experienced a problem with audio see it resolved; and if this requires fixups, we won’t do the same without consulting anyone who has had benefit from the former improvements in this thread.
Edit: now pinged the users who can provide the best feedback (i.e. those who experienced problems)
Sam
Now you’re putting words in my mouth. I said I was hesitant, which is quite different, and I’d say understandable after the September update broke this again for me when you told me it should fix it.
But if you want to continue being hostile to someone who is trying to help, I can’t stop you.
I’m not really interested in squabbling and just want to resolve the technical issues at hand.
I want to make it clear that we won’t push any changes until we have something that works for everyone.
The manual workaround still works and is persistent.
If you can reproduce the problems reported by others; then I’d be grateful for any logs as well as a description of how to reproduce these problems.
If you have any queries or questions then feel free to give me a quick call
Cheers,
Sam
Hi,
I’m willing to help if I get clear instructions.
Setup:
- Vero 4K OSMC 2017.10-1 / AML-M8AUDIO, HDMI / 7.1 (normally full pass-through)
- AV Sony STR DN840, 7.1 speaker setup
I own a test reference DVD with VOB files containing an AC3-5.1 sound to check the correct cabling and location of the speakers.
Playing one of the test files with the Vero 4K WITHOUT pass-through gives the following results
Vero 4K speaker setup incoming AV HDMI signal
---------------------------------------------------------------------
2.0 LPCM (2 / 0)
2.1 - 7.1 LPCM (3/4.1) but only FL and FR have sound
So, if this from help, please, give detailed instructions how to collect the required data, where to upload the vob file etc.
BTW: On a Pi 2 B with same setup the mapping to LPMC works as expected.
Can you confirm your .conf file please? Can you post
ls -al /usr/share/alsa/cards/AML-M8AUDIO.conf
Just checking. Sorry if it’s above somewhere.
No, this was pure OSMC 2017.10-1.
Found now Sam’s post dated September 14th and activated the workaround (which seems to work so far) but recognized differences to the Pi 2 B behavior when mapping AC3 to LPCM, meanings
FL - front left
FR - front right
FC - front center
BL - back left
BR - back right
SL - side left
SR - side right
LFE - subwoofer
Vero/Pi Speaker Setup AC3 signal mapping from Pi AC3 signal mapping from Vero 4K
4/5/7.X BL/R -> (SL/R + BL/R) BL/R -> SL/R
So in my environment with the Vero 4K the back left+right sound is mapped to the side speakers, only. The back/rear speakers are not used at all.
root@osmc-vero4k:~# ls -al /usr/share/alsa/cards/AML-M8AUDIO.conf
-rw-r–r-- 1 root root 793 Oct 31 14:56 /usr/share/alsa/cards/AML-M8AUDIO.conf
root@osmc-vero4k:~#
BTW: With the workaround I get some short metallic squeakings in the back speakers (most times BL) if I do 10 secs forward or backward jumps playing the test vob file.
Hi @JimKnopf
Thanks for your feedback. The pops are not ideal but being worked on – there is unfortunately a fine balance between muting I2S promptly enough to hide clicks during changes and muting for too long.
Can you post a debug log from Pi2 and Vero 4K?
Cheers
Sam
Hi @sam_nazarko,
here the logs from the test VOB with AC3 5.1 → multichannel LPCM
Pi:
https://paste.osmc.tv/buhowaqohi
Vero 4K:
https://paste.osmc.tv/qazevogoni
mediainfo of test file:
http://paste.osmc.io/raw/rugavagasu
Believing mediainfo, the AC3 contains FL, FR, FC, LFE … and SL + SR.
My personal opinion: From the strict logic the Vero 4K behavior with my environment is correct to map the side/surround channels just to the side/surround speakers. From the effect the Pi’s behavior/mapping is much better in this scenario.
Many thanks. That’s useful confirmation of previous tests. One thing I would be interested in is what happens if you play the same file on Vero with channels set to 5.1 in Kodi. (I don’t own an AVR or more than 2 speakers, so can’t test it myself.)
There are in fact two issues here - a) getting OSMC to play the right number of channels in the right order, with silence on the unused channels, and b) getting OSMC to tell receivers what the channel layout is. The above test should help with (b).
Hi @grahamh,
as mentioned above:
All Kodi speaker setups 4.0, 4.1, 5.0, 5.1, 7.0 and 7.1 with the Vero 4K map the side speaker signals to the side speakers in a real 7.1 speaker environment but do not touch the back/rear speakers like the Pi does.
Looking at the various possible combinations of sound channels in the media file and possible speaker setups, I think it is somewhat painful to design any single mapping strategy … but it has to be done and afterwards simplified by rules while coding, see also Surround sound - Wikipedia .
Here the log set of my Vero 4K test AC3 5.1 mapped to LPMC with 5.1 speaker setup:
https://paste.osmc.tv/asolozazac
Yes, I’ve gone through the whole thread again this morning! Just wanted to see if there was any difference in the logs, or possibly what your AVR is telling you if Kodi is set to 5.1. AFAICT, all the above tests were done with 7.1 set. Logically, if you set 5.1, kodi should be saying to the AVR ‘I’m sending you 5.1’ even if it’s a 7.1 signal.
We ought to be able to define different layouts (eg 5.1 and 5.1 ‘side’ per the wikipedia table) as different alsa devices which could be chosen in kodi settings, if they are not automatically recognised from the stream metadata. And the upmix behaviour you noted on Pi could be done the same way. I’m discussing with Sam.
Hi Graham,
With regards to issue a) ‘osmc sending silence to the unused channels’ is part of the problem. If the channels are not used, they shouldn’t be sent/mapped, period. Sending silence tells the avr they are being used, when no sound is going to be actually output. Getting osmc to output a 5.1 track as 5.1 and not 7.1 is the major problem, yes?
I also think channel labelling is a problem. And this is causing some confusion.
On a 5.1 track, media info will say FL,FR,FC LFE, SL and SR (surrounds).
They are being output to what is labelled FL,FR,FC,LFE, BL and BR (back), but are still being sent to the correct speakers, the proper surrounds. Would re-labelling SL and SR as BL and BR and vice versa help?
Sorry if this is going over old ground.
Well I didn’t say ‘sending’ 
We just need to stop spurious noises on unused channels.
If I can find out where media info is getting its data from, then we can fix that.
Apologies for misquoting you…it’s a confusing issue!
Did a little (google)-research and found several articles/threads that mediainfo is not doing good job, here. From the Wikipedia article I referenced before you can find Surround sound - Wikipedia … and this suggests the channel layout will be determined by the used audio format and simply the used index of the channel. This would increase the complexity to the next level. Wouldn’t it helpful to look into the Pi’s code or is this already handled inside a driver you do not have access to the code?