[Forsaken]

Try substituting "plughw" for "hw". I think AES0 has to be interpretted by Alsa proper rather than passing it directly to the kernel driver.

Same error as before.

[cbxbiker61]

Well, aplay streams multichannel audio (DTS, AC-3, ..., etc.) correctly through HDMI to my receiver. Meaning that alsa works correctly. XBMC passes movies soundtracks correctly as well. It is just multichannel music I have trouble with. "IsPassthrough - false" always in log.

ATI HD63xx (E350) => Onkyo 808.

Yes, music is taking a different path than video in the xbmc code. I'm pretty sure that the music path never attempts to use pass-through. That would be the reason why IsPassthrough is always false for music. I haven't looked at that for quite a while ...well now I have. Here's the relevant bit in PAPlayer.cpp.

Code:

/* Open the device */
    m_pAudioDecoder[num] = CAudioRendererFactory::Create(
      m_pCallback         , //pCallback
      m_channelCount [num], //iChannels
      m_channelMap   [num], //channelMap
      m_sampleRate   [num], //uiSamplesPerSec
      m_bitsPerSample[num], //uiBitsPerSample
      false               , //bResample
      true                , //bIsMusic
      false                 //bPassthrough
    );

I don't have much in the way of multi-channel encoded music.

[cbxbiker61]

Same error as before.

Well, I just looked at the alsalib code and AES0 should be valid for any hdmi card. So I wonder if you're actually selecting the right output device. What I'd do in your case is strip out a high-def stream and then see if I can get it to play with aplay, it's a bit easier to debug this way. I use a couple of scripts to get/test the hd stream.

mkvextract will extract a track from an mkv file if you have one of those. Otherwise you can use ffmpeg for something else. Once you've extracted a high-def track, you can use spdifer (part of AudioFilter) to put it in spdif format.

This is the command I use to play a dts-hd track.

Code:

aplay -D hdmi:CARD=NVidia,DEV=0,AES0=6 -c8 -fs16_le -r192000 test.file.spdif768

This is the command I use to play a std dts track.

Code:

aplay -D hdmi:CARD=NVidia,DEV=0,AES0=6 -c2 -fs16_le -r48000 test.file.spdif

[cbxbiker61]

You have fixed the issue for the individual VOBs. Great step forward! It is getting more subtle now Turns out the menus are 25fps and the movies are 50 fps. On switching from a 25fps VOB to a 50fps one, things go wrong. By jumping up and down 30s once, everything I have tried can be made to play correctly now.

For many of my DVDs I have just made an ISO, so that menus and options are still present. Thanks for the mkv hint, but converting them with makemkv looks like a work-around as it would take quite some time and menus/options could be lost. As the issue appears with ISOs, it also means that the original DVDs don't play correctly anymore. That cannot be the intention?

I just committed a change to both audiofilter and xbmc repos. Now this change is really subtle compared to the last. Basically the first audio frame of the VOB's may be invalid. Previously I would just drop the frame. Now the code will instead repeat the last valid frame. So it should make the audio transitions between VOB's more fluid.

Makemkv does mark chapters, so you can move pretty rapidly forward and back, but yes you lose the menus. (To me that's mostly a bonus )

As far as the 25/50fps VOB transitions go...I don't see anything in the audio code which should affect that (I noticed when transitioning to the main video that the audio was playing fine, just the video was not behaving). I'm in the US, so 25/50fps is not common here. I was pleasantly surprised to see 50fps work correctly.

[sjongele]

I just committed a change to both audiofilter and xbmc repos. Now this change is really subtle compared to the last. Basically the first audio frame of the VOB's may be invalid. Previously I would just drop the frame. Now the code will instead repeat the last valid frame. So it should make the audio transitions between VOB's more fluid.

Makemkv does mark chapters, so you can move pretty rapidly forward and back, but yes you lose the menus. (To me that's mostly a bonus )

As far as the 25/50fps VOB transitions go...I don't see anything in the audio code which should affect that (I noticed when transitioning to the main video that the audio was playing fine, just the video was not behaving). I'm in the US, so 25/50fps is not common here. I was pleasantly surprised to see 50fps work correctly.

Were you able to test it on a full ISO, or just on a single VOB? I have rebuilt AudioFilter and XBMC; the issue still appears. If it helps I can make a 30/60 fps ISO with the same issue available as well

[Forsaken]

Well, I just looked at the alsalib code and AES0 should be valid for any hdmi card. So I wonder if you're actually selecting the right output device. What I'd do in your case is strip out a high-def stream and then see if I can get it to play with aplay, it's a bit easier to debug this way. I use a couple of scripts to get/test the hd stream.

mkvextract will extract a track from an mkv file if you have one of those. Otherwise you can use ffmpeg for something else. Once you've extracted a high-def track, you can use spdifer (part of AudioFilter) to put it in spdif format.

This is the command I use to play a dts-hd track.

Code:

aplay -D hdmi:CARD=NVidia,DEV=0,AES0=6 -c8 -fs16_le -r192000 test.file.spdif768

This is the command I use to play a std dts track.

Code:

aplay -D hdmi:CARD=NVidia,DEV=0,AES0=6 -c2 -fs16_le -r48000 test.file.spdif

No no sound that way either, just quiet.

[cbxbiker61]

Were you able to test it on a full ISO, or just on a single VOB? I have rebuilt AudioFilter and XBMC; the issue still appears. If it helps I can make a 30/60 fps ISO with the same issue available as well

Did you try with straight Alsa? If it behaves the same between the PulseAudio code and the Alsa code, I can't think of anything in the audio code that could be causing it. If PulseAudio pass-through doesn't work and Alsa does, then there could be a rate calculation that may be the issue.

[cbxbiker61]

No no sound that way either, just quiet.

It seems aplay should be making the same complaint about AES0, if you're using the same Card id. Was it?

Post the output of "aplay -l" and the aplay command you're using to test.

Also, did you say that some pass-through streams are working, but just not dts-hd? If that's the case
then I could take a different approach.

[Forsaken]

It seems aplay should be making the same complaint about AES0, if you're using the same Card id. Was it?

Post the output of "aplay -l" and the aplay command you're using to test.

Also, did you say that some pass-through streams are working, but just not dts-hd? If that's the case
then I could take a different approach.

No I realized that the device was wrong, it should be 0 for hdmi but the result was the same, no audio.

Yes regular DTS/DD works.

aplay -D hdmi:CARD=0,DEV=0 -c8 -fs16_le -r192000 dts.spdif

Code:

**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: ALC889 Analog [ALC889 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: ALC889 Digital [ALC889 Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

aplay -L

Code:

hdmi:CARD=Intel,DEV=0
    HDA Intel, HDMI 0
    HDMI Audio Output

[cbxbiker61]

No I realized that the device was wrong, it should be 0 for hdmi but the result was the same, no audio.

Yes regular DTS/DD works.

aplay -D hdmi:CARD=0,DEV=0 -c8 -fs16_le -r192000 dts.spdif

Code:

**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: ALC889 Analog [ALC889 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: ALC889 Digital [ALC889 Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

aplay -L

Code:

hdmi:CARD=Intel,DEV=0
    HDA Intel, HDMI 0
    HDMI Audio Output

I just checked in code to deal with this problem in my xbmc repo. This entails adding a maxpassthroughbandwidth option to xbmc advanced settings.

You can now limit the bandwidth of high-def streams so that you'll be able to play the dts-core when your hardware doesn't support the high bandwidth requirement of dts-hd.

In ~/.xbmc/userdata add the maxpassthroughbandwidth to limit bandwidth to suitable rate for your system.

768000 is the default setting
Values to try: 48000, 192000 and 192001

48000 should always work, but will alway limit you to dts-core. 192000 and 192001 (they are equivalent in bandwidth by have different channel/frequency mappings) may work and will pass-through dts-hd. There are some dts-hd videos that will exceed this bandwidth and cause distortion.

cat ~/.xbmc/userdata/advancedsettings.xml

Code:

<advancedsettings>
        <loglevel>0</loglevel>
        <audio>
                <errorcorrectionspeed>10</errorcorrectionspeed>
                <maxpassthroughbandwidth>192000</maxpassthroughbandwidth>
        </audio>
</advancedsettings>

[Forsaken]

I just checked in code to deal with this problem in my xbmc repo. This entails adding a maxpassthroughbandwidth option to xbmc advanced settings.

You can now limit the bandwidth of high-def streams so that you'll be able to play the dts-core when your hardware doesn't support the high bandwidth requirement of dts-hd.

In ~/.xbmc/userdata add the maxpassthroughbandwidth to limit bandwidth to suitable rate for your system.

768000 is the default setting
Values to try: 48000, 192000 and 192001

48000 should always work, but will alway limit you to dts-core. 192000 and 192001 (they are equivalent in bandwidth by have different channel/frequency mappings) may work and will pass-through dts-hd. There are some dts-hd videos that will exceed this bandwidth and cause distortion.

[/CODE]

Ok I will give it a try tonight but afaik my hw should support it, it's a core i3 (not sandy bridge the previous one).

[sjongele]

Did you try with straight Alsa? If it behaves the same between the PulseAudio code and the Alsa code, I can't think of anything in the audio code that could be causing it. If PulseAudio pass-through doesn't work and Alsa does, then there could be a rate calculation that may be the issue.

I have tried the following:
* Dharma: OK
* pre-Eden: OK
* your pre-Eden, ALSA: not OK
* your pre-Eden, Pulse: not OK

I don't where it is, but as the "default" pre-Eden works correctly, I would assume there is a relation to AudioFilter. Hope you can find it; I'm using your pre-Eden as default media center

[Forsaken]

Both 192000 and 192001 worked fine with movies I tried that gave no sound before.

Edit: Ok so I used the wrong xbmc build, now I don't get audio with 192001 but with 192000 I get audio and the receiver says DTS-MA.

[megakha]

Yes, music is taking a different path than video in the xbmc code. I'm pretty sure that the music path never attempts to use pass-through. That would be the reason why IsPassthrough is always false for music. I haven't looked at that for quite a while ...well now I have. Here's the relevant bit in PAPlayer.cpp.

Code:

/* Open the device */
    m_pAudioDecoder[num] = CAudioRendererFactory::Create(
      m_pCallback         , //pCallback
      m_channelCount [num], //iChannels
      m_channelMap   [num], //channelMap
      m_sampleRate   [num], //uiSamplesPerSec
      m_bitsPerSample[num], //uiBitsPerSample
      false               , //bResample
      true                , //bIsMusic
      false                 //bPassthrough
    );

I don't have much in the way of multi-channel encoded music.

I have played around with the code, it seems that PAPlayer changes the data itself, and sends stereo only to passthrough. I have changed settings to use DVDAudio player for music, It helped - now I am getting passthrough, but most of DTS tracks are not recognized correctly (hence, not played) although PAPlayer did play 2 channels from it before. aplay plays DTS correctly

[cbxbiker61]

I have tried the following:
* Dharma: OK
* pre-Eden: OK
* your pre-Eden, ALSA: not OK
* your pre-Eden, Pulse: not OK

I don't where it is, but as the "default" pre-Eden works correctly, I would assume there is a relation to AudioFilter. Hope you can find it; I'm using your pre-Eden as default media center

I actually don't think it's AudioFilter, but more the fact that pass-through is being handled just a bit differently than non-pass-through.

After looking at the code a bit, I'm thinking the problem lies with the way that DVDNAV_NAV_PACKET's are being handled. You'll notice DVDNAV_NAV_PACKET DISCONTINUITY messages in your log. I think that code needs to be improved. You'll find the interesting code in DVDInputStreamNavigator.cpprocessBlock:line 461+ and DVDPlayer.cpp:OnDVDNavResult:line 3185+. It actually looks like in OnDVDNavResult someone had planned to flush it out a bit more. I don't think it's handling the timestamp changes properly when starting a new VOB.

I'm focused on true-hd support so I don't have time to look at this at the moment.