XBMC PulseAudio passthrough support (including Nvidia) is available

After I got a wonderful Onkyo/Polk Audio surround system I just had to have DTS/AC3 passthrough working. So I spent two weeks writing code getting it to happen. It's working great. I fixed a bug or two in XBMC's pulseaudio implementation on the way.

In the process I ported Ac3Filter to Linux (and renamed it AudioFilter, so as not to confuse the two (I changed too many interfaces and improved it's performance). Anyway AudioFilter has become my primary audio library with regard to passthrough support.

I'm currently working on dts-hd format support. My first step is going to be to passthrough the dts-5.1 core. Then if I can get proper doc for the dts-hd format I'll try to pass that through as well. FFmpeg doesn't seem to grok dts-hd very well either, it's too slow and causes stutters.

It'll probably be a week or so before I can handle dts-hd streams in AudioFilter.

So far I can only passthrough them in a rudimentary way (put them through ffmpeg then play with aplay) but that is more just to see my receiver say it is getting the formats since it loses video.

But seeing my receiver saw 7.1ch DTS-HD MA was nice.

What is the ffmpeg command you are using to mux the dts-hd file? I would like to analyze what it's doing with the the hd portion of the stream.

I'm playing dts-hd mkv's now (I'm stripping off the hd portion currently). I updated AudioFilter and the Xbmc AudioFilter patch. For some reason Xbmc doesn't like the dts timestamps in the dts-hd stream made with MakeMkv. I added a patch for Xbmc which fixes (works around) this.

Also not when I played the files with aplay using the following command, even if I was only doing a DTS-HD MA 5,1 I still had to use -c8 (receiver reported only 5.1) when I tried -c6 I only got static (and the receiver reported 5.1 Linear PCM)

Also not when I played the files with aplay using the following command, even if I was only doing a DTS-HD MA 5,1 I still had to use -c8 (receiver reported only 5.1) when I tried -c6 I only got static (and the receiver reported 5.1 Linear PCM)

I think the problem is that I was using svn. Usually when the change source controls they delete the old repository and put a README in there to let you know about the new repository. Should be good to go now that I've rebuild the git version.

If you didn't know about moving to git, I doubt you are going to know this since it just happened but it looks like due to fighting the ffmpeg is getting branched with most devs going to the new one. So you may have to start watching http://www.libav.org for updates that affect you.

I hope it doesn't turn into a problem where some features are one version and some in the other.

Source: ffmpeg-devel mailing list which I just skimmed so may not have the clearest understanding of what is happening.

I haven't reviewed the patches but so they don't fall into the void and under our radar (which is easy on the forum!) could you please fork our repo, patch it and send a pull request. Alternatively, but we prefer the first way, you can simply start a trac ticket with the patches.

topfs2 Wrote:I haven't reviewed the patches but so they don't fall into the void and under our radar (which is easy on the forum!) could you please fork our repo, patch it and send a pull request. Alternatively, but we prefer the first way, you can simply start a trac ticket with the patches.

Yeah, that sounds like a plan. PulseAudio has just recently created a branch to work out their long term pass-through support. I'll be testing against that branch as soon as I can. Not sure when Pulse will be ready to roll in their "new" pass-through code. Probably be a while, and then I'll be ready to submit "official" patches.

In the meantime, I'll be analyzing the dts-hd support. It is nice though that blu-ray rips with dts-hd will play today with the code as it stands.

OK, I've tested dts-hd passthrough with pulse and I've got the test working. Now it's just a matter of coding up a proper solution. Probably 4 to 5 days. Then I'll test with the pulseaudio passthrough branch and see if they've added a couple of features I want/need.

Yeah, if it can't be used in pulse which is found in our target distros I'd say its probably better to wait, we don't generally want to keep that type of development code in our mainline but a fork on github is the way to go about it I would say, that way other pulseaudio bleeding edge users can use your fork if they wish. When they merge in their branch and distros start having (or they will have it until our next release is going in) you can submit a pull request and we will pull it in if we want.

Awesome to see that the pulseaudio fellows finally are working on this, it has been such a pain that they haven't had support for this already.

Also, you might want to check out gnif's AE branch, this will be merged into mainline hopefully before eden so it might make sense if you target that with your patches. It is still in somewhat of a flux but most of the interfaces ought to be stable now.