XBMC PulseAudio passthrough support (including Nvidia) is available - Printable Version
+- XBMC Community Forum (http://forum.xbmc.org)
+-- Forum: Development (/forumdisplay.php?fid=32)
+--- Forum: Development (/forumdisplay.php?fid=93)
+--- Thread: XBMC PulseAudio passthrough support (including Nvidia) is available (/showthread.php?tid=96316)
- joeyhhdhtpc - 2011-09-30 17:32
cbxbiker61 Wrote:PulseAudio 1.0 is out. It seems to work fine with my git branch.
NM, I figured it out
- Polyamid - 2011-09-30 20:12
It is not in the Lucid repos at the moment. Does anyone have a ppa to install Pulse 1.0 save on Ubuntu 10.04?
- virtualshock - 2011-10-08 17:09
I ran the script that Shadow provided and everything seemed to install fine. I opened up XBMC and I see in the Audio settings 2 devices that have (PulseAudio) at the end. Under passthrough device I don' have any (PulseAudio) options though. I have 2 ALSA ones and then custom. Should I be seeing a (PulseAudio) option under Passthrough? MP3s play fine with either (PulseAudio) device chosen but movies with DTS or DD 5.1 can't initialize the audio device.
- virtualshock - 2011-10-08 19:23
Never mind. I fixed it by rebuilding pulseaudio after I corrected the JSON dependency problem that I had. I then rebuilt XBMC and my movies are using passthrough. I have been trying to get passthrough to work for months in XBMC. Thanks for your work cbxbiker61 and shadow for the script.
I used to use AC3Filter to upconvert my MP3s to DD5.1 back when I used Windows. Did your changes make this possible on Ubuntu? It would be cool to have that functionality when playing MP3s or streaming music from Spotify.
- eternalsword - 2011-10-09 23:28
DTS-HD MA 6.1 as in Star Wars bluray set does not appear to be working, though I think it is an issue with pulse and not xbmc. pulse appears to crash. If I set it so that dts passthrough is disabled, everything works fine, though it has to buffer every 8 or so minutes. I'll try out pulse 1.0 later. using my DTS 5.1 track for now instead.
- Ford_Prefect - 2011-10-13 07:18
PulseAudio doesn't support DTS-HD, mostly because I had no way to test it. I think it should be reasonably straight-forward to add support. If you can test this, I can try to put up a patch somewhere.
Edit: I just remembered that cbxbiker61's branch is using passthrough a bit differently from the default, so it's probably working just fine. Specifically, it's not using the new formats API (which would allow users to set what formats their receiver supports and then have XBMC negotiate a format with PA). It's doing bitstreaming similar to how it works with ALSA. That's possibly next steps if cbxbiker61's still up to it.
Great work, btw!
- eternalsword - 2011-10-14 21:22
Is the formats API from XBMC or PA?
Ford_Prefect Wrote:Specifically, it's not using the new formats API (which would allow users to set what formats their receiver supports and then have XBMC negotiate a format with PA).
- cbxbiker61 - 2011-10-15 02:25
eternalsword Wrote:Is the formats API from XBMC or PA?
It's in PA. I plan to dig into it sometime in the near future.
- eternalsword - 2011-10-22 06:50
Would be good to do another pull from trunk or eden as the skinning engine has changed slightly, so skins being updated for eden are breaking (missing labels). Is there a git command that can be run on our ends to do this, or is it more involved than that due to the amount of changes made to the code?
Edit: I'm not exactly sure, but I think https://github.com/xbmc/xbmc/commit/f20f1924fbbc35f787342365a1a15a801967778a might be what causes the breakage in upstream skins. Will try patching with this and report back.
Edit2: Unfortunately it appears the changes are more extensive. Would be more worth the time to just do a full pull than figure out the combination of commits necessary to get things working.
- cbxbiker61 - 2011-10-22 22:34
eternalsword Wrote:Would be good to do another pull from trunk or eden as the skinning engine has changed slightly, so skins being updated for eden are breaking (missing labels). Is there a git command that can be run on our ends to do this, or is it more involved than that due to the amount of changes made to the code?
I'll update the repository today or tomorrow.
- cbxbiker61 - 2011-10-22 23:32
OK, I just rebased the repository.
BTW, the code works fine with PulseAudio 1.1.
- eternalsword - 2011-10-23 02:21
cbxbiker61 Wrote:OK, I just rebased the repository.
- aragorn - 2011-11-04 10:25
I compiled this branch many months ago, and its been working fine.
Last night however i decided i wanted to update it to the latest version. At first i tried a git pull on the xbmc source and ran make again, but something failed during the compile, so i deleted the three source directories, redownloaded everything and recompiled from scratch using the script posted on page 5.
It compiled successfully, however now, i'm missing the pulseaudio options from the audio output menu and also missing the HD Audio passthru options that get added. The menu just looks like a normal build of XBMC.
Any ideas what i've done wrong?
- cbxbiker61 - 2011-11-04 22:19
aragorn Wrote:I compiled this branch many months ago, and its been working fine.
There's a check for Pulse Audio versions that support passthrough, otherwise passsthrough code is disabled. PA_PROTOCOL_VERSION is defined in /usr/include/pulse/version.h. Of course you might also have a /usr/local/include/pulse/version.h. You should be able to figure it out from there.
- aragorn - 2011-11-05 00:45
I've checked that file and its saying protocol 23. Version numbers are all displayed as "Unknown" though which is a bit odd?
I'm wondering if its a problem with Pulseaudio itself?
I realised that my recompilation and reinstall had deleted my original config files for pulse. I think i've readded them correctly (i had to add a line with the alsa-sink module and device ID) as now typing pulseaudio at the commandline actually works, whereas before it was spewing lots of errors about not being able to open the device.
If for some reason pulse failed to start with XBMC would the menu options vanish? Or would they remain onscreen regardless?