v18 PCM 3.0 Output from HDMI
#16
(2021-05-05, 10:35)black_eagle Wrote: Thanks.  Two things there stood out to me.  Firstly, HDMI - ARC AV AMP.  Makes me wonder if you are connected PC-->TV-->AMP ?  ARC has caused me issues in the past so if you have it enabled, maybe try without it and see if that makes a difference.

Secondly, this bit is generic to all OS's and tells me that Kodi has seen the correct channel layout (we will have got it from the hint, which does contain the correct channel map).

xml:
2021-05-02 21:14:33.645 T:2032 INFO <general>: CDVDAudioCodecFFmpeg::GetChannelMap - FFmpeg reported 3 channels, but the layout contains 0 trying hints
2021-05-02 21:14:33.645 T:2032 INFO <general>: Creating audio stream (codec id: 65536, channels: 3, sample rate: 48000, no pass-through)

But, when WASAPI returns the channel layout we can use it gives us this.

xml:
2021-05-02 21:14:33.890 T:5748 DEBUG <general>: CActiveAESink::OpenSink - trying to open device WASAPI:default
2021-05-02 21:14:33.979 T:5748 INFO <general>: CAESinkWASAPI::InitializeExclusive: WASAPI Exclusive Mode Sink Initialized using: AE_FMT_S24NE4MSB, 48000, 4
2021-05-02 21:14:33.979 T:5748 DEBUG <general>: CActiveAESink::OpenSink - WASAPI Initialized:
2021-05-02 21:14:33.979 T:5748 DEBUG <general>: Output Device : default
2021-05-02 21:14:33.979 T:5748 DEBUG <general>: Sample Rate : 48000 2021-05-02 21:14:33.979 T:5748 DEBUG <general>: Sample Format : AE_FMT_S24NE4MSB
2021-05-02 21:14:33.979 T:5748 DEBUG <general>: Channel Count : 4 2021-05-02 21:14:33.979 T:5748 DEBUG <general>: Channel Layout: FL, FR, BL, BR
2021-05-02 21:14:33.979 T:5748 DEBUG <general>: Frames : 2400 2021-05-02 21:14:33.979 T:5748 DEBUG <general>: Frame Size : 16

Does directsound do the same thing?  I know that's not recommended for Win but might be worth a try.  I can try and add some more logging to the wasapi stuff and get another test build which might show more clearly if indeed kodi requests the right layout and it's the win driver giving us the incorrect one back but this is shooting in the dark a little as I can't test it!

Thank you for looking at this. The Amp name is confusing, no ARC involved, the brand is Arcam.

I did discover something interesting about this issue by setting various fixed channel configs with Wasapi audio. None of the odd channel numbers detect correctly:
2.1 outputs 4.0
3.0 outputs 4.0 (Same problem as this test file)
5.0 outputs 5.1
7.0 outputs 7.1

When using the "Optimal" setting mono PCM media is output as stereo and 6.1 PCM is output as 7.1 (Back left maps to center back).

The other things that is interesting is both 4.0 and 3.1 work correctly and the amp detects between them correctly. If I set a fixed 3.1 config then that clip plays correctly and upmixes correctly so not very user friendly but it is a good workaround. I suppose no one likes logic exceptions but 3.1 would be a much better output choice for a 3.0 signal than 4.0.

My hardware is Intel 8th gen I3 integrated graphics (UHD 630). Can anyone else using Windows with an AVR confirm what their results are for the odd fixed speaker configs above?

Directsound just seems to use stereo so seems to be a non starter. Edit: You were right looks like Directsound support far fewer channel configs than KS/WASAPI:
https://docs.microsoft.com/en-us/windows...nel_config

Does the fallback to hints change also effect the music player? I tried with some 4 channel Flac with the WAVE_FORMAT_EXTENSIBLE header set for 3.1 and 4.0 (SL/SR) and Kodi did not change the channel mapping.
Reply
#17
No, it doesn't affect the music player as far as I know.  In any case, FLAC should work fine.

THanks for the link, that stuff is not just related to directsound.   My best guess at this point is that as we can't go down in the number of channels, only up, is that the driver returns the first 4 channel map that it has which is the quad layout.  That is bourne out by your log showing FL,FR,BL,BR  where what we really want is FL,FR,FC,Null.  I don't have a Windows dev env to test this theory with though at the moment.  I will try and get one set up over the coming weekend and see if I can dig a bit deeper.
Learning Linux the hard way !!
Reply
#18
(2021-05-07, 09:42)black_eagle Wrote: No, it doesn't affect the music player as far as I know.  In any case, FLAC should work fine.

THanks for the link, that stuff is not just related to directsound.   My best guess at this point is that as we can't go down in the number of channels, only up, is that the driver returns the first 4 channel map that it has which is the quad layout.  That is bourne out by your log showing FL,FR,BL,BR  where what we really want is FL,FR,FC,Null.  I don't have a Windows dev env to test this theory with though at the moment.  I will try and get one set up over the coming weekend and see if I can dig a bit deeper.

Probably out of scope but FLAC also supports WAVE_FORMAT_EXTENSIBLE header as do some other audio only formats so the rather helpful change in that build would also be relevant to the audio player. Did you create the fallback_to_hints build? Is the git branch public?

There are a couple of things from my testing which would seem like sensible changes to Kodi from my POV (Maybe @fritsch can add his opinion).
I'll make the assumption that most people using multi channel PCM output either have an HDMI connected AVR or directly connected speakers.
There appears to be nothing in HDMI spec that is actually used by most devices for communicating back supported PCM channel maps which is likely part of the problem.
Support for Dolby and DTS bit stream channel mapping is way better as that is dealt with by decoder spec on the AVR end and it seems support for a range of speaker mapping is mandatory.

1) Kodi defaults to FL+FR+SBL+SBR when given 4 PCM channels with no mapping (At least it does when using Windows Wasapi). This leads to Kodi not working for most AVRs with 4.0 PCM as they do not support that mapping as mentioned by @HomerJau. The link I gave earlier shows Microsoft don't consider the widely supported by AVR FL+FR+SL+SR as a standard config so defaulting to FL+FR+SL+SR might need to be an advanced option but would greatly improve PCM 4.0 over HDMI to AVR compatibility.

2) Some sort of advanced options to map input channel maps to output channel maps would be great. For example being able to map 3.0 FL+FR+C to 3.1 for that test file in my case would outright resolve the issue with the sample file at the start of this thread with no downsides.
Reply
#19
Yeah, I think the issue is that although Kodi's wasapi interface checks for a supported channel format, it doesn't check that the format we got back from the driver is indeed the one we wanted.  This is similar to how the Linux stuff worked previously without the addition of falling back to hints.  In that case there was no channel map at all so Kodi asks FFmpeg for a default layout for 3 channels.  That default layout is/was 2.1 (Fl, FR, LFE) so put the centre channel on LFE.  Obviously, that's not what we want at all.  As the hints do contain the channel layout then falling back to that layout in the event that we don't have one already does give the correct channel layout.

Alsa (Linux sound system) returns FL, FR, FC, Null when requested to open that layout so all is good.  Wasapi appears to return FL, FR, BL, BR (quad) when what we really wanted was FL, FR, FC, BC/Null which is surround according to MS.  Kodi does have mappings for this in it's wasapi interface https://github.com/xbmc/xbmc/blob/master...h#L70-L104 so it should be 'just!' a question of checking the mappings and requesting the right one.

As I say, just guessing right now by looking at the code until I can get Kodi building on Windows.
(2021-05-07, 11:45)Krobar Wrote: Did you create the fallback_to_hints build? Is the git branch public?

Yes, I did.  There isn't a branch as such, just a PR against master.  https://github.com/xbmc/xbmc/pull/19671
Learning Linux the hard way !!
Reply
#20
I have looked at this further and it seems that although the 'fallback_to_hints' supplies the correct channel mapping now to the WASAPI driver, that Windows won't open that channel map.  What happens next is that there is a list of mappings with the more common ones earlier in the list than the more obscure and exotic mappings.  Kodi goes through this list and tries to open the first mapping it finds that has more channels than the actual required number.  In the case of FL, FR, FC the first mapping that Kodi tries to open that has more channels is FL, FR, BL, BR because that comes before FL, FR, FC, BC.  That succeeds and so we get the wrong layout.

I have adjusted the code to instead try and open the first layout that contains the same channels as the input source.  In this case, FL, FR, BL, BR is ignored because there is no FC channel.  Instead Kodi will attempt to open FL, FR, FC, BC.  My amp shows 4.0 as you would expect from that, but the important thing is that the narration is on FC and the sample file plays correctly. Checking for matching channels (+ extra if needed by Windows) seems to me to be a better method to select a channel map, rather than just the number of channels.  I've tested this against stereo, 5.1 & 7.1 sources as well as your sample file and in all cases I have had no regressions. (Not to say there won't be any, I just haven't found them yet!).

If I can figure out Git on Windows then I'll push the branch to my github page and see if I can generate a test build for you to try.
Learning Linux the hard way !!
Reply
#21
(2021-05-12, 14:10)black_eagle Wrote: I have looked at this further and it seems that although the 'fallback_to_hints' supplies the correct channel mapping now to the WASAPI driver, that Windows won't open that channel map.  What happens next is that there is a list of mappings with the more common ones earlier in the list than the more obscure and exotic mappings.  Kodi goes through this list and tries to open the first mapping it finds that has more channels than the actual required number.  In the case of FL, FR, FC the first mapping that Kodi tries to open that has more channels is FL, FR, BL, BR because that comes before FL, FR, FC, BC.  That succeeds and so we get the wrong layout.

I have adjusted the code to instead try and open the first layout that contains the same channels as the input source.  In this case, FL, FR, BL, BR is ignored because there is no FC channel.  Instead Kodi will attempt to open FL, FR, FC, BC.  My amp shows 4.0 as you would expect from that, but the important thing is that the narration is on FC and the sample file plays correctly. Checking for matching channels (+ extra if needed by Windows) seems to me to be a better method to select a channel map, rather than just the number of channels.  I've tested this against stereo, 5.1 & 7.1 sources as well as your sample file and in all cases I have had no regressions. (Not to say there won't be any, I just haven't found them yet!).

If I can figure out Git on Windows then I'll push the branch to my github page and see if I can generate a test build for you to try.

Thanks again.

This sounds like much better behaviour but I think this selection order would be even better:
1) Source Channel Map
2) Source Channel Map + LFE
3) Source Channel Map + Any Other Channel
4) First channel map with more channels than source

Adding the LFE channel is preferable to BC / Mono Surround or any other channel because it does not lead to silent channels when upmixing.
Reply
#22
(2021-05-12, 18:58)Krobar Wrote: Adding the LFE channel is preferable to BC / Mono Surround or any other channel because it does not lead to silent channels when upmixing.

Oh, I agree.  But, this is dependent on the Windows driver, not Kodi.  There is a fresh new build for you to try here. Not only does it include the hints from the previous build but it also changes the method of selecting the output channels to the one I explained earlier. I have also re-ordered the channel maps so that f.e 3.0 comes before 3.1, then 4.0, 4.1 etc etc. If you run it with debugging enabled then it will log each output map that it tries and whether the driver can open it. The Intel HDMI audio driver on my laptop doesn't support 3.0 (FL,FR,FC) or 3.1 (FL,FR,FC,LFE) but it does support 4.0 (FL,FR,FC,BC). There is no BC speaker in my setup but I doubt that matters as the channels are mapped 1:1 and zero's sent to the extra (BC) channel by Kodi.

I know my amp is capable of accepting 3.0 over HDMI as that's what I get with Linux so I can only assume that being unable to open that mapping is a Windows driver issue, rather than a Kodi one as I can see that layout requested in the log. Anyway, as I said earlier, it needs testing not just with your original sample but against other multi-channel files to ensure that there is no regression from how Kodi selects the channel map now. When testing, the layouts that Kodi attempts to open should always contain at least the same channels as the input. Means with your sample file that where previously Kodi would have selected FL,FR,BL,BR (which is wrong) it will now select FL,FR,FC,BC as that layout contains FC.
Learning Linux the hard way !!
Reply
#23
(2021-05-15, 16:13)black_eagle Wrote:
(2021-05-12, 18:58)Krobar Wrote: Adding the LFE channel is preferable to BC / Mono Surround or any other channel because it does not lead to silent channels when upmixing.

Oh, I agree.  But, this is dependent on the Windows driver, not Kodi.  There is a fresh new build for you to try here. Not only does it include the hints from the previous build but it also changes the method of selecting the output channels to the one I explained earlier. I have also re-ordered the channel maps so that f.e 3.0 comes before 3.1, then 4.0, 4.1 etc etc. If you run it with debugging enabled then it will log each output map that it tries and whether the driver can open it. The Intel HDMI audio driver on my laptop doesn't support 3.0 (FL,FR,FC) or 3.1 (FL,FR,FC,LFE) but it does support 4.0 (FL,FR,FC,BC). There is no BC speaker in my setup but I doubt that matters as the channels are mapped 1:1 and zero's sent to the extra (BC) channel by Kodi.

I know my amp is capable of accepting 3.0 over HDMI as that's what I get with Linux so I can only assume that being unable to open that mapping is a Windows driver issue, rather than a Kodi one as I can see that layout requested in the log. Anyway, as I said earlier, it needs testing not just with your original sample but against other multi-channel files to ensure that there is no regression from how Kodi selects the channel map now. When testing, the layouts that Kodi attempts to open should always contain at least the same channels as the input. Means with your sample file that where previously Kodi would have selected FL,FR,BL,BR (which is wrong) it will now select FL,FR,FC,BC as that layout contains FC.
Thanks again.

This new build behaves as perfectly as possible with the sample at the beginning of this thread (I get PCM 3.1) which other than an incorrect readout on the receiver display has no disadvantages. Smile

I tried a PCM 1.0 Mono MKV video and this still got upconverted to stereo which I don't think is correct as my receiver should be OK to do "1.1".

I also tried a mixture of Flac files within the music player. The 5.0 one produced 5.1 output and the 6.1 file produced 7.1 output which is correct and how it behaved before. However the 4 channel Flac marked with the WAV header as 3.1 played as the default FL/FR/SBL/SBR so looks like hints are not being used by the music player.

Its odd we get slightly different supported formats when both using Intel graphics. My setup is an 8th gen I3 with UHD630 graphics, what is yours?
Reply
#24
(2021-05-16, 11:50)krobar Wrote: I tried a PCM 1.0 Mono MKV video and this still got upconverted to stereo which I don't think is correct as my receiver should be OK to do "1.1".

Hmmm, what does it say in the log when you try to open that? Could be that the driver doesn't support mono output (which should be on FC only).
 
(2021-05-16, 11:50)Krobar Wrote: I also tried a mixture of Flac files within the music player. The 5.0 one produced 5.1 output and the 6.1 file produced 7.1 output which is correct and how it behaved before. However the 4 channel Flac marked with the WAV header as 3.1 played as the default FL/FR/SBL/SBR so looks like hints are not being used by the music player.

Yeah, this doesn't touch the music player at all, just the video player.
 
(2021-05-16, 11:50)Krobar Wrote: Its odd we get slightly different supported formats when both using Intel graphics. My setup is an 8th gen I3 with UHD630 graphics, what is yours?

Hehe, it's an old laptop that happens to have an HDMI output on it.  It's a Pentium T4200 @ 2.00Ghz and the display adapter is a Mobile Intel 4 Series.  The HDMI audio driver dates from 15/03/2010 so pretty old!  Strangely, the up-to-date Windows driver (late 2020) fails to produce any sound on anything but FL & FR.  None of the surround or LFE channels work with it even though they all appear correctly in the dialog box. 

Putting Windows on my desktop & dev kit stuff ain't gonna happen Smile but I'm OK running it on this old lappy.
Learning Linux the hard way !!
Reply
#25
(2021-05-16, 14:13)black_eagle Wrote:
(2021-05-16, 11:50)krobar Wrote: I tried a PCM 1.0 Mono MKV video and this still got upconverted to stereo which I don't think is correct as my receiver should be OK to do "1.1".

Hmmm, what does it say in the log when you try to open that? Could be that the driver doesn't support mono output (which should be on FC only).
 
(2021-05-16, 11:50)Krobar Wrote: I also tried a mixture of Flac files within the music player. The 5.0 one produced 5.1 output and the 6.1 file produced 7.1 output which is correct and how it behaved before. However the 4 channel Flac marked with the WAV header as 3.1 played as the default FL/FR/SBL/SBR so looks like hints are not being used by the music player.

Yeah, this doesn't touch the music player at all, just the video player.
 
(2021-05-16, 11:50)Krobar Wrote: Its odd we get slightly different supported formats when both using Intel graphics. My setup is an 8th gen I3 with UHD630 graphics, what is yours?

Hehe, it's an old laptop that happens to have an HDMI output on it.  It's a Pentium T4200 @ 2.00Ghz and the display adapter is a Mobile Intel 4 Series.  The HDMI audio driver dates from 15/03/2010 so pretty old!  Strangely, the up-to-date Windows driver (late 2020) fails to produce any sound on anything but FL & FR.  None of the surround or LFE channels work with it even though they all appear correctly in the dialog box. 

Putting Windows on my desktop & dev kit stuff ain't gonna happen Smile but I'm OK running it on this old lappy.

Fair enough; mine is actually a Linux server which passes through the display card to a Windows VM (GVT-d). I'm still not sure if the lack of support for odd channel configs is a Windows thing or an Intel thing, hopefully a Windows user with an AMD or Nvidia display card will try your build and report back.

Log for the new build is below, the mono file is "Network (1976).mkv":
https://paste.ee/p/kBOrV
Reply
#26
That's a good test.  It shows for your original sample that you get
Quote: 2021-05-16 10:37:09.524 T:4840 DEBUG <general>: AESinkWASAPI: Format [FL, FR, FC] not supported by driver
2021-05-16 10:37:09.524 T:4840 DEBUG <general>: AESinkWASAPI: Trying matching channel layout [FL, FR, FC, LFE]

My driver doesn't support that so I get [FL, FR, FC, BC]. Both maps work and produce the correct output so the logic there appears to work. For your mono file, could you supply me with a 30 second sample of it? Looking at your log, it appears that there is no matching hint for that file and thus we get a default layout (probably FL,FR) before we even get to the wasapi stuff. With a short sample I can dig into this a bit further to try and see whats going on.

Thanks.
Learning Linux the hard way !!
Reply
#27
(2021-05-17, 09:45)black_eagle Wrote: produce the correct output so the logic there appears to work. For your mono file, could you supply me with a 30 second sample of it? Looking at your log, it appears that there is no matching hint for that file and thus we get a default layout (probably FL,FR) before we even get to the wasapi stuff. With a short sample I can dig into this a bit further to try and see whats going on.

Thanks for looking at this and sorry about the late response. You are right there is no hint for the mono file, my understanding is that MakeMKV only attaches hints to PCM files with more than 2 channels so this is probably out of scope for your PR.

Sample:
https://drive.google.com/file/d/1DOUEfHj...sp=sharing

An assumption that a mono file should be played through the centre speaker is probably safe but how you handle systems that don't have a centre channel or where a suitable output format cannot be found (Or just doesn't work) I assume could be more difficult. A way of overriding default channel maps to use when no hint is present in advancedsettings would be excellent. For example I could set 1.1 as the default for mono and FL+FR+SL+SR as the default for 4 channels. The lack of support for FL+FR+SBL+SBR with receivers is very common but I understand why changing the default would be difficult as Directsound doesn't support anything else.
Reply
#28
(2021-05-21, 10:38)Krobar Wrote: sorry about the late response.

No problem, everyone has a life and stuff to do.  Our audio dev may have some free time coming up and has some thoughts about how to handle the hints etc.  No doubt he can improve on my suggestion.  For the Windows stuff, I really need to speak to a Windows dev and see what they think about my changes.  Logs tend to indicate I'm on the right lines and I think selecting a mapping by number of channels rather than the channels we actually want is the wrong solution but I need to run it past some people to make sure.

Thanks for the sample, I'll do some testing with it and see what gives.
Learning Linux the hard way !!
Reply
#29
(2021-05-21, 22:02)black_eagle Wrote:
(2021-05-21, 10:38)Krobar Wrote: sorry about the late response.

No problem, everyone has a life and stuff to do.  Our audio dev may have some free time coming up and has some thoughts about how to handle the hints etc.  No doubt he can improve on my suggestion.  For the Windows stuff, I really need to speak to a Windows dev and see what they think about my changes.  Logs tend to indicate I'm on the right lines and I think selecting a mapping by number of channels rather than the channels we actually want is the wrong solution but I need to run it past some people to make sure.

Thanks for the sample, I'll do some testing with it and see what gives.
Audio devs seem to be even more in demand and rarer than other Kodi devs Smile Hoping one day they will manage to look at this confirmed bug:
https://github.com/xbmc/xbmc/issues/17427
Reply
#30
(2021-05-23, 12:25)Krobar Wrote: Audio devs seem to be even more in demand and rarer than other Kodi devs

Sadly yes.  Anyway, I have not yet had chance to have a play with your second sample file, but I have raised https://github.com/xbmc/xbmc/pull/19786 to see if I can get some feedback regarding the Windows changes.
Learning Linux the hard way !!
Reply

Logout Mark Read Team Forum Stats Members Help
PCM 3.0 Output from HDMI0