2011-12-05, 22:58
cbxbiker61 Wrote: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 Wrote:Try substituting "plughw" for "hw". I think AES0 has to be interpretted by Alsa proper rather than passing it directly to the kernel driver.
megakha Wrote: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.
/* 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
);
Forsaken Wrote:Same error as before.
aplay -D hdmi:CARD=NVidia,DEV=0,AES0=6 -c8 -fs16_le -r192000 test.file.spdif768
aplay -D hdmi:CARD=NVidia,DEV=0,AES0=6 -c2 -fs16_le -r48000 test.file.spdif
sjongele Wrote: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?
cbxbiker61 Wrote: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.
cbxbiker61 Wrote: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
sjongele Wrote: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 Wrote:No no sound that way either, just quiet.
cbxbiker61 Wrote: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.
**** 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
hdmi:CARD=Intel,DEV=0
HDA Intel, HDMI 0
HDMI Audio Output
Forsaken Wrote: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
aplay -LCode:**** 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
Code:hdmi:CARD=Intel,DEV=0
HDA Intel, HDMI 0
HDMI Audio Output
<advancedsettings>
<loglevel>0</loglevel>
<audio>
<errorcorrectionspeed>10</errorcorrectionspeed>
<maxpassthroughbandwidth>192000</maxpassthroughbandwidth>
</audio>
</advancedsettings>
cbxbiker61 Wrote: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]
cbxbiker61 Wrote: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 Wrote: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.
sjongele Wrote: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