Multichannel audio incorrectly mapped

I understand that Sam, the aac is decoded to pcm, displays as multi channel audio, but sound is only sent to front left and right speakers. And the problem started after the June update.

1 Like

Did that… Honestly, doesn’t sound like a problem related to some AVRs only. My receiver takes multichannel PCM from every other device without a problem.

I guess, the behaviour of multichannel audio not working would be occuring regardless of the fileformat. Nearly no audio files are formats that can be streamed without conversion to PCM (except some rare DTS files maybe) and the Vero 4k doesn’t support DSD atm, if I’m correct. So, the problem would occure pretty much regardless of which surround audio file format is played back :wink:

1 Like

As far as I understand, this is a general problem affecting everyone who decode any kind of multi-channel audio format to multi-channel PCM. The result is stereo only PCM output, no matter how many channels the original source contains.

My AVR does not support the new HD formats, so I want to output multi-channel PCM with correct channel configuration for content with those formats.

1 Like

What needs to happen to make progress here? Remote access to my box? I’m desperate for a fix as there is now a lot of 10bit + multichannel AAC content, like Game of Thrones.

Hi @swrobel

It’s being worked on. I’ll update this thread when we have progress.

Some workarounds have been discussed above in the interim.

Thanks for your patience.

Sam

Hi guys,

Quick update.

Can you give this a go (via SSH)? I would normally make this available via the staging repository but presently it’s in a state of flux as we prepare for Debian Stretch.

cp /usr/share/alsa/cards/AML-M8AUDIO.conf /home/osmc/AML-M8AUDIO.bak
sudo wget https://raw.githubusercontent.com/osmc/osmc/2b2b23dffcd1967216d79b27bd8a26130546de23/package/vero3-userland-osmc/files/usr/share/alsa/cards/AML-M8AUDIO.conf -O /usr/share/alsa/cards/AML-M8AUDIO.conf
reboot

If it doesn’t work / goes wrong, you can restore things:

cp /home/osmc/AML-M8AUDIO.bak /home/osmc/AML-M8AUDIO.conf
reboot

Can you also test that passthrough works as expected? Someone seems to have made some changes to my AV receiver; so I won’t be able to verify things until a bit later.

Cheers,

Sam

Tested every imaginable format and all seem to be working!!!

That sounds nefarious…

Can you also check this good behaviour survives a re-boot?

I’m getting some weird effects: as soon as I try watching TV, all sounds disappear, and I cannot get them back by restoring the original AML-M8AUDIO.conf and just issuing alsactl restore. Re-boot is needed.

Hi Sam.

5.1 aac is still registering as 7.1 on my receiver. It is receiving a 7.1 signal, even though there are only 5.1 channels. The context button shows 5.1 channels being available also. And something funny, the surrounds are displayed as back left and back right, but the sound is coming out of my surround left and surround right(where it should be). With nothing from the actual BL and BR even though my receiver would 'upscale ’ the audio to fill the back ones.

5.1 shows as FL,FR,FC,LFE,BL,BR
7.1 shows as FL,FR,FC,LFE,BL,BR,SL,SR

I would have thought surround channels would take preference in importance over back channels. But I’m no expert. (please help)!

I am also getting a hiss through the speakers when I start some aac files, it goes away when I stop/start again. I will test more tomorrow.

Passthrough seems to be all ok, working as usual.
And thanks for your continued work on this Sam, it is much appreciated.

Regards,

Jason.

Did a reboot, I still have sound.

It does. @Brozzie I tested and my receiver gets a 7.1 signal even though my settings in OSMC are 5.1/Optimized and the test files I’ve been using are definitely only 5.1. I have a 5.1.4 setup so I can’t test the issues w/ surround vs surround back. The first time I tested, I heard some weird hiss after playback on a few of the files but I can’t seem to reproduce it now.

Apologies if you’ve done so before but can we see:

  • A screenshot of Kodi audio settings
  • Debug log
  • MediaInfo of file played.

The current kernel code does seem to be favouring the output capabilities of the receiver rather than the content being played, i.e. if it’s PCM and you’re playing a 2.0 track, you’ll get 7.1 LPCM out. I’ve yet to see an ill effect of this however.

Re. hiss, I will check on it. I had a hiss (sounds like static), but the problem was caused by me not rebooting after making some changes.

Sam

Unfortunately my AV receiver is quite complex. It took me a few days and a forum to get it working. The remote is extremely sensitive, and a single button press (Zone) resets a multitude of settings that must be manually reconfigured.

Thank you for clarifying.

Hi Sam.

I will send the info later today.

So if a 2.0 pcm track is being sent as 7.1 does the Vero do any processing to fill the other channels?

My issue, with 5.1 being sent as 7.1 is that my receiver will not try fill the empty channels if it already sees a full 7.1 signal being sent. It will assume they have content. If it receives the actual 5.1 track/signal, then it will expand/upscale that to fill a 7.1 system. I also have the choice of just playing it as is in 5.1.

Regards.

Debug log playing 5.1 aac.
Http://paste.osmc.tv/mifahufome

EDIT

Media info

General
Unique ID : 239110069919603085383177426917387658691 (0xB3E2ECA3448E8E959B6A2F100D37E5C3)
Complete name : Q:\2160p\Central Intelligence 2016 UNRATED (2160p x265 10bit Joy).mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 5.06 GiB
Duration : 1h 56mn
Overall bit rate : 6 216 Kbps
Encoded date : UTC 2017-04-06 10:46:15
Writing application : mkvmerge v9.9.0 (‘Pick Up’) 64bit
Writing library : libebml v1.3.4 + libmatroska v1.4.5
Writing frontend : StaxRip 1.4.1.3
DURATION : 01:55:06.816000000
NUMBER_OF_FRAMES : 1993
NUMBER_OF_BYTES : 54783
_STATISTICS_WRITING_APP : mkvmerge v9.9.0 (‘Pick Up’) 64bit
_STATISTICS_WRITING_DATE_UTC : 2017-04-06 10:46:15
_STATISTICS_TAGS : BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.0
Codec ID : V_MPEGH/ISO/HEVC
Duration : 1h 56mn
Width : 3 840 pixels
Height : 1 600 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Writing library : x265 2.3+23-97435a0870be:[Windows][GCC 6.3.0][64 bit] 10bit
Encoding settings : cpuid=1173503 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=3840x1600 / interlace=0 / total-frames=167486 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=23 / keyint=250 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=8 / scenecut=40 / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / no-tskip / nr-intra=50 / nr-inter=50 / no-constrained-intra / strong-intra-smoothing / max-merge=2 / limit-refs=3 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / early-skip / rskip / fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=0.30 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=abr / bitrate=6000 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=2 / cplxblur=20.0 / qblur=0.5 / ipratio=1.40 / pbratio=1.30 / aq-mode=3 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / refine-level=5
Default : Yes
Forced : No
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Color range : Limited

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : HE-AAC / LC
Codec ID : A_AAC
Duration : 1h 56mn
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz / 24.0 KHz
Compression mode : Lossy
Delay relative to video : 31ms
Language : English
Default : No
Forced : No

Text
ID : 3
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Language : French
Default : No
Forced : No

Menu
00:00:00.000 : en:(01)00:00:00:000
00:09:32.238 : en:(02)00:09:32:238
00:21:47.848 : en:(03)00:21:47:848
00:32:26.861 : en:(04)00:32:26:861
00:47:37.103 : en:(05)00:47:37:103
00:57:28.528 : en:(06)00:57:28:528
01:03:15.750 : en:(07)01:03:15:750
01:17:23.221 : en:(08)01:17:23:221
01:26:11.540 : en:(09)01:26:11:540
01:36:29.992 : en:(10)01:36:29:992
01:48:21.411 : en:(11)01:48:21:411
01:56:26.604 : en:(12)01:56:26:604

Hi

There won’t be any processing, those channels would not carry any audio. There’s no smart things, or rather attempts at doing something smart like ProLogic.

There’s some background on why things are the way they are here: https://trac.kodi.tv/ticket/16903

I will check with @fritsch_xbmc as he is Kodi’s AudioEngine guy and knows best on this subject.

Sam

Then should the 2.0 track not be sent as 2.0 so the receiver can do the necessary processing. Likewise with 5.1.

This was working until the June release.

There were changes in both Kodi and the AML drivers in June. It’s not clear (to me) whether they are compatible and which caused the change in behaviour.

@Brozzie Can you post a debug log (above log doesn’t seem to be a debug log) which shows playback of a file? You only need to upload kernel log / dmesg and the Kodi log.

Here you go Sam, HTTPS://paste.osmc.tv/ulomexujel

Regards.

So, I had time to test now… Same behaviour as described by others here already: now, finally, the surround FLAC file is played through my 5 ear level speakers - it works!!! (Also passthrough is working as expected…) But I also experience the issue that a multichannel PCM signal is triggering a 7 channel layout with my receiver (as I have set 7.1 channels in the HDMI settings of my Vero 4k).
The receiver mixes those down to 5 channels (as I don’t have 7 speakers - I have set it to 7.1 nonetheless to let the AVR do the downmixing of 7.1 channel sources), so I cannot comment on this behaviour, but believe it would be the same here:

So, first of all: Thanks for obviously fixing the issue! :grinning:

But I’d also like to add that it’s not very convenient that the Vero 4k can playback 2.0 sources as stereo, but only knows one surround PCM mode: the one set in the audio settings. I’d very much ask for an option where surround PCM would also be played back with true-to-source channel layout: 5.1 as 5.1 and 7.1 as 7.1 - basically a “best match” option not only for bit-depth and sampling rate, but also for PCM source channel layout. It only seems logical, when using a very expensive AVR, to leave the AVR the actual option to blowup 5.1 to 7.1. That isn’t possible, if the remaining two channels between a 5.1 source and the 7.1 PCM setting are simply filled with two blank channels by the Vero 4k.

2 Likes