v18 PCM 3.0 Output from HDMI
#31
If I could ask a wish, please don't make mono play through the center speaker. IMHO that is a non-standard configuration, it should be played as double mono through both front speakers. How to play mono is rather something that can and should be set in the amp. Also, center speaker is usually not of the same quality as the stereo speakers. Thanks!
Reply
#32
(2021-05-23, 22:00)HeresJohnny Wrote: If I could ask a wish, please don't make mono play through the center speaker.

Well, the code that I have altered won't make it play through the centre speaker unless that is how it is encoded in the video.  The idea behind the changes is to ensure that the output channels always include at least the input channels (with the possibility of extra empty channels) so that output always matches input as closely as the Windows driver allows.

The good news is that the changes have been approved so will go in at some point.  The bad news is that the current pr includes a "fix" further back in the audio chain where the actual channel layout of the input file is determined.  Although it "works", I am reliably informed that it is still actually a best guess and that there is a better way to get the correct channel mapping.  Once that's sorted properly then the Windows changes can be merged.
Learning Linux the hard way !!
Reply
#33
(2021-05-23, 13:34)black_eagle Wrote:
(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.

What do you think about changing the default 4 channel layout (When no hints) from FL-FR-SBL-SBR to FL-FR-SL-SR? The reason I ask is I think a lot of the compatibility issues with 4.0 are due to most modern receivers only supporting FL-FR-SL-SR.

https://github.com/xbmc/xbmc/blob/af1feb...yWin.h#L75
Reply
#34
(2021-06-06, 12:55)Krobar Wrote: What do you think about changing the default 4 channel layout (When no hints) from FL-FR-SBL-SBR to FL-FR-SL-SR? The reason I ask is I think a lot of the compatibility issues with 4.0 are due to most modern receivers only supporting FL-FR-SL-SR.

There is no need.  Once the changes to the WASAPI driver are merged it will no longer match on number of channels (which is how it works right now) but on what the actual channel input map is.  So, if your file is FL,FR,SBL,SBR then that is what you will get, if it's FL,FR,SL,SR then you will get that.  You might actually get more channels (LFE for example) depending on what the particular WASAPI driver reports back that it is capable of but it should always be a layout that contains at least the same ouput channels as the input.

The hints are really only required where Kodi (ffmpeg) is unable to determine the actual channel layout from the audio frames.  This is the case with your original sample file which doesn't appear to contain the channel layout in each audio frame (or I am looking in the wrong place!).
Learning Linux the hard way !!
Reply
#35
(2021-06-06, 17:36)black_eagle Wrote:
(2021-06-06, 12:55)Krobar Wrote: What do you think about changing the default 4 channel layout (When no hints) from FL-FR-SBL-SBR to FL-FR-SL-SR? The reason I ask is I think a lot of the compatibility issues with 4.0 are due to most modern receivers only supporting FL-FR-SL-SR.

There is no need.  Once the changes to the WASAPI driver are merged it will no longer match on number of channels (which is how it works right now) but on what the actual channel input map is.  So, if your file is FL,FR,SBL,SBR then that is what you will get, if it's FL,FR,SL,SR then you will get that.  You might actually get more channels (LFE for example) depending on what the particular WASAPI driver reports back that it is capable of but it should always be a layout that contains at least the same ouput channels as the input.

The hints are really only required where Kodi (ffmpeg) is unable to determine the actual channel layout from the audio frames.  This is the case with your original sample file which doesn't appear to contain the channel layout in each audio frame (or I am looking in the wrong place!).
There must be something I don't understand. If it is multichannel PCM with no channel mapping header then surely there has to be a default?
Reply
#36
(2021-06-06, 17:52)Krobar Wrote: There must be something I don't understand. If it is multichannel PCM with no channel mapping header then surely there has to be a default?

There has to be some sort of header, else the file would be unplayable.  Your file has a header describing the layout but Kodi didn't honour that.  Both PR's have been merged now, so now it will.   As I understand it, the issue with your sample is that Kodi looks in two places for the channel layout info.  Firstly, it uses FFprobe to read the data from the headers (that reports FL,FR,FC) but then it looks in the audio frames (no channel layout in them in your file) to confirm it.  As one layout said three channels and one layout said no channels, Kodi just opened the first three channel default layout it could.

With the new code, as long as the number of channels in the audio frame matches the No of channels from FFprobe, Kodi will try to open the layout obtained by FFprobe.  If the numbers don't match only then fall back to some default layouts, although if they don't match there is likely something wrong with the file.
Learning Linux the hard way !!
Reply
#37
(2021-06-07, 12:10)black_eagle Wrote:
(2021-06-06, 17:52)Krobar Wrote: There must be something I don't understand. If it is multichannel PCM with no channel mapping header then surely there has to be a default?

There has to be some sort of header, else the file would be unplayable.  Your file has a header describing the layout but Kodi didn't honour that.  Both PR's have been merged now, so now it will.   As I understand it, the issue with your sample is that Kodi looks in two places for the channel layout info.  Firstly, it uses FFprobe to read the data from the headers (that reports FL,FR,FC) but then it looks in the audio frames (no channel layout in them in your file) to confirm it.  As one layout said three channels and one layout said no channels, Kodi just opened the first three channel default layout it could.

With the new code, as long as the number of channels in the audio frame matches the No of channels from FFprobe, Kodi will try to open the layout obtained by FFprobe.  If the numbers don't match only then fall back to some default layouts, although if they don't match there is likely something wrong with the file.

Understood and the new behaviour is much better. What I mean is the WAVE_FORMAT_EXTENSIBLE header is optional (At least it is for Flac) so not there will be some multichannel PCM files around with no hints or embedded mapping info.
Reply
#38
In the event of there being no channel mapping at all, Kodi will ask FFmpeg for a default layout based upon the number of channels in the file.  As we are beholden to what FFmpeg returns, this may or may not be correct.  Note that this is before the audio chain gets to the WASAPI driver.

I'd also point out that the original code is something like ~10 years old and has worked pretty well for the vast majority of users before this change.  It's only when Kodi starts encountering non-standard stuff or edge-cases that things start to go amiss.  This is why we like standards!

Given a channel layout somewhere, Kodi will try to open an output containing at least that channel map and ignore any extra channels it may contain.  If there is no channel layout at all then it will 'best guess' via FFmpeg using the number of channels.  But, if you want some funky channel layout, why wouldn't you specify it somewhere?  It would be unwise for example to throw a four channel file in and expect Kodi to know whether you want Quad or Surround (FL,FL,BL,BR vs FL,FR,FC,BC) or indeed 3.1 without a channel map to tell it.

If everything fails, you will either get stereo as a last resort or there is something wrong with your configuration/driver. This scenario is unlikely though.
Learning Linux the hard way !!
Reply

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