PulseAudio coexistance with XBMC?
#1
I've been struggling with xbmc to find a way to make it work with pulse and my spdif interface, as I need it for it's network sink abilities. Thus far the only way I can seem to make it behave is to simply kill it as per all the other recommendations. I've found using mplayer by itself works fine with my configuration without having to kill pulse, so why does xbmc have these issues? I just finished compiling the current svn pulled today, as well as ubuntu jaunty repository ppa's.

My setup is this: Ubuntu Jaunty, pci sound card using stereo analog channels along with iec958 output to a receiver. Xbmc has digital audio enabled, ac3, dts, with normal sound to "default", and pass-through for "iec958", both valid with aplay -L. I tried in vein to make it work sanely with only the iec958, but I run into the problem with pulse locking to the device. Now in xbmc I have pulse running on the analog channels just fine, with no pulse control on the iec958 interface. I've even tried disabling hal and statically setting the pulse sink to the analog channels. Any time I launch xbmc, it still tries first to talk to pulse, then tries alsa on the iec958 port, and responds it as busy. If I kill pulse, it connects fine to the iec958, but not unless. Again, mplayer uses the iec958 just fine WITH pulse still operational. I get this from debugs:

23:29:20 T:2958842768 M:1655480320 ERROR: PulseAudio: Passthrough not possible
23:29:20 T:2958842768 M:1655480320 DEBUG: CALSADirectSound::CALSADirectSound - Channels: 2 - SampleRate: 48000 - SampleBit: 16 - Resample false - Codec DTS - IsMusic false - IsPassthrough true - audioDevice: default
23:29:20 T:2958842768 M:1655480320 DEBUG: Initialize - using alsa device iec958:AES0=0x6,AES1=0x82,AES2=0x0,AES3=0x2

and later:

23:29:20 T:2958842768 M:1656713216 ERROR: Initialize - failed to open custom device iec958:AES0=0x6,AES1=0x82,AES2=0x0,AES3=0x2, retry with default iec958
23:29:20 T:2958842768 M:1656713216 ERROR: Initialize - pcm_open_lconf, alsa error: -16 - Device or resource busy
23:29:20 T:2958842768 M:1656713216 ERROR: Creating a Null Audio Renderer, Check your audio settings as this should not happen

I saw others in the sticky pulse thread respond they're using it with pulse just fine, but any ideas why mine will not allow me to bind to the iec958 port with pulse? TIA....
Reply
#2
PulseAudio does not support passthrough, as it's said in log.

There is a ticket on pulseaudio trac about it, I suggest you go there and poke them about it, if they implement it someone here will for sure alter the code needed in XBMC for it to work.

So for now you'll have to do one of the following choices:
1. Loose network sound and use ALSA for passthrough
or
2. Get network sound and loose passthrough.

Cheers,
Tobias.
If you have problems please read this before posting

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

Image

"Well Im gonna download the code and look at it a bit but I'm certainly not a really good C/C++ programer but I'd help as much as I can, I mostly write in C#."
Reply
#3
Top,

I know it does not support passthrough, hence why im going the route of providing pulse it's own analog channel. The problem is xbmc still seems to insist on using pulse at all, even when I give it a dedicated iec958 interface that pulse doesn't touch at all. This is why i say, mplayer itself works just dandy on its own attaching to the dedicated spdif, with pulse working on analog. Ideally standard sounds SHOULD work through "default", which on my system pulse attaches to only analog stereo jacks, but "iec958" specifies a direct alsa attachment to the device for pass-through functionality.

Clear as mud? Smile

My question is why does xbmc insist on even trying pulse, when I have allocated the iec958 interface as its spdif out port? I even tried using direct alsa nomenclature of hwplug:0,2 (my iec958 device) but the same wrangling seems to take place. It still seems to engage pulse to pipe the passthrough, which is incorrect in this situation, rather it should only talk alsa direct to it's device which works indicated by mplayer as stated.

There should be some clear differentiation between the analog and digital ports, though that doesn't seem to be the case within xbmc. This seems to effectively solve the "pulse blows, remove it" problem if xbmc only would cleanly attach to the iec958 device. Seems like improper behavior in the code for which sound api/devices to deal with. I haven't started fumbling with the source direct to see why, I was hoping someone more in the know with the sound code might have a more obvious solution or experienced the same issue already.

Long term, i know pulse is being a pisser not supporting passthrough, as this seems to be the biggest issue with its overall (highly) unfavorable disposition amongst linux users, including myself. Seems like it wouldn't be that hard to provide a software shunt to fifo pcm via pulse to alsa, but what do I know...

Thanks!
Reply
#4
Well, when:
Quote:23:29:20 T:2958842768 M:1655480320 ERROR: PulseAudio: Passthrough not possible
Happens in log XBMC doesn't try pulse at all, we decide passthrough way earlier and when our PulseAudio renderer handed a passthrough stream it just fails cleanly and XBMC continues to try ALSA instead, so in this case it's exactly the same as if you wouldn't have had pulse enabled on xbmc at all(--disable-pulse on configure). So it must be something else that destroys it for you and something else that makes it work in mplayer, but I can ensure you we don't connect to pulseaudio on passthrough, we probably do on plughw and such though.

My bet is SDL Audio which XBMC uses but not mplayer which by default in jaunty uses PulseAudio.

Cheers,
Tobias
If you have problems please read this before posting

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

Image

"Well Im gonna download the code and look at it a bit but I'm certainly not a really good C/C++ programer but I'd help as much as I can, I mostly write in C#."
Reply
#5
Interesting, I was thinking the error indicated it tried and failed, moving onto alsa, but still failing. I know little about sdl, but I'm assuming that it works in switching audio to the right stream, but why would it presume iec958 to be busy while pulse is active?

I just read your article about pulse and xbmc again, and caught this:

"Navigational sounds is still dependent on SDL, export SDL_AUDIODRIVER=esd before entering XBMC might help."

Now navigational sounds under xbmc in my config work just fine, outputting via the "default" and subsequent pulse system, where I have the SDL package "libsdl1.2debian-pulseaudio" to enable it to use pulse globally. So how exactly does xbmc then use SDL in attaching to the spdif device when an ac3/dts movie is played that it is erroring? The only thing I can think is that since SDL is pointing at pulse by default, that pulse is attaching to the iec port causing it to be busy, or it's simply misreporting something via faulty error checking. Can SDL be bypassed to attach to the alsa device direct, hopefully with more success than via SDL?

I'll try switching SDL to use alsa globally in ubuntu to see if that helps, see what I can figure out barking up its tree.

Just out of curiosity, how exactly to you and others use your sound devices WITH pulse that you're not running into this frustration? I can't imagine my issue is all that dissimilar to others that have issues getting this to work, only I'm assuming running without pulse simply isn't a problem for them.
Reply
#6
You should do export SDL_AUDIODRIVER=esd if you WANT XBMC to output to pulseaudio, which you can't do in your case as your trying to do passthrough, which pulse audio does not support.

So my guess is, SDL starts up pulse which locks the alsa device (pulse does this by design to prevent random errors and miss-use of the alsa device from other programs while it uses it). So when you try to start a passthrough stream it tries alsa which can't start because pulse have locked it.

Thats why people have little issues with pulse as they either have pulse and use it with XBMC, or they don't have pulse at all and both XBMC and SDL will fallback to use ALSA.
However you could try export SDL_AUDIODRIVER=alsa (I think it's correct atleast) which might force sdl to not poke pulse at all, but I'm not sure on how SDL handles this, and I believe SDL is abit patched in ubuntu.

Also on a sidenote, your endevour is really unsupported, one should NEVER use both pulse audio and alsa at the same time, pulse is designed around having exclusive access to the output. I'm pretty sure though that you can setup your local pulseaudio server to have alsa output but that info is best gathered over at PulseAudio trac.

Cheers,
Tobias
If you have problems please read this before posting

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

Image

"Well Im gonna download the code and look at it a bit but I'm certainly not a really good C/C++ programer but I'd help as much as I can, I mostly write in C#."
Reply
#7
Tobias, that's about what I was thinking. I tried the SDL_AUDIODRIVER=alsa and esd last night, no effect in keeping sdl from locking the device. Does SDL offer any kind of status to confirm lock/unlock that perhaps it would just simply wait to unlock the device before moving on to alsa? Seems none of this would be an issue if pulse could be avoided being probed for spdif all together, since passthrough in pulse not likely to happen (unfortunately).

Somewhat radical, but compiling xbmc without pulse support seems optional to remedy this, no? I might try this later for grins.

I agree it's somewhat "unsupportable", but until the pulse guys stop sticking their head in the sand when it comes to pass-through support, it's about the only way I can see xbmc working seamlessly between pcm and non-pcm streams. Working with only the spdif output simply isn't an option due to pulse being the way it is, and this seems like the most "graceful" approach to pleasing all scenarios. If I'm missing something, I'm definitely game for suggestion.

Right now, I'm using the xbmc system as the audio head to my home theater system, ideally using other pc's to stream transient audio to the receiver, and subsequently the rest of the house that is going to have speakers driven from that amp. The network sink allows for this, so frankly if it came down to pulse or xbmc, it would be pulse considering mplayer works fine minus a nice media gui. It seems xbmc would be easier to adapt to this purpose with some proper status/error handling vs. pulse implementing a shim pass-through layer that seems like a pipe dream. Frustrating to say the least.

Regardless, I appreciate your fishing with me on this adventure to find a suitable solution to please all the people all the time.

-mb
Reply
#8
mikus Wrote:Tobias, that's about what I was thinking. I tried the SDL_AUDIODRIVER=alsa and esd last night, no effect in keeping sdl from locking the device. Does SDL offer any kind of status to confirm lock/unlock that perhaps it would just simply wait to unlock the device before moving on to alsa? Seems none of this would be an issue if pulse could be avoided being probed for spdif all together, since passthrough in pulse not likely to happen (unfortunately).
I have no clue on how to get any confirmation unfortunately.
mikus Wrote:Somewhat radical, but compiling xbmc without pulse support seems optional to remedy this, no? I might try this later for grins.
Unfortuanatly no, the only thing that configure does (I did it so I know) is that it removes the PulseAudio Renderer, which won't touch or initialize pulse audio if the output is passthrough, you could do it though as it might help in music as it might not trigger passthrough.

The logic is, if you read code:
PulseAudioRenderer creation
Code:
if (stream is passthrough)
  return
else
  Initialize pulseaudio.
So you can see it won't, or shouldn't matter.

mikus Wrote:I agree it's somewhat "unsupportable", but until the pulse guys stop sticking their head in the sand when it comes to pass-through support, it's about the only way I can see xbmc working seamlessly between pcm and non-pcm streams. Working with only the spdif output simply isn't an option due to pulse being the way it is, and this seems like the most "graceful" approach to pleasing all scenarios. If I'm missing something, I'm definitely game for suggestion.

Right now, I'm using the xbmc system as the audio head to my home theater system, ideally using other pc's to stream transient audio to the receiver, and subsequently the rest of the house that is going to have speakers driven from that amp. The network sink allows for this, so frankly if it came down to pulse or xbmc, it would be pulse considering mplayer works fine minus a nice media gui. It seems xbmc would be easier to adapt to this purpose with some proper status/error handling vs. pulse implementing a shim pass-through layer that seems like a pipe dream. Frustrating to say the least.

Regardless, I appreciate your fishing with me on this adventure to find a suitable solution to please all the people all the time.

-mb

Well then you can't disable alsa in the pulseaudio server as you need it Smile

So I don't have any idea on how to fix it. Although it's possible iirc to do digital but only PCM via pulseaudio if that's an option.

You could try sudo apt-get remove libsdl1.2debian-pulseaudio as it should remove the possiblity for sdl to do pulseaudio.

Cheers,
Tobias
If you have problems please read this before posting

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.

Image

"Well Im gonna download the code and look at it a bit but I'm certainly not a really good C/C++ programer but I'd help as much as I can, I mostly write in C#."
Reply
#9
So I played around with this last night, and dug into some of the cpp files to see wtf was going on, and found some interesting results.

Using xbmc with pulse compiled made no difference which libsdl renderer I used, it just still always seemed to go through the same steps which resulted in the pcm device being locked or "busy".

I then recompiled without pulse (--disable-pulse), which ultimately got me to somewhat have functioning pcm output without having to kill pulse, but in doing so lost the analog portion for navigational sounds. Music, video, and pcm audio streams worked just fine. Kind of wacky however how it all worked...

Using xbmc sans pulse, I would set SDL_AUDIODRIVER=alsa, install libsdl1.2debian-alsa, and check to find that analog default sounds worked, but pcm would not (busy).

Seting SDL_AUDIODRIVER=esd, install libsdl1.2debian-alsa, and check to find that AC3/DTS worked, but not navigation sounds.

Basically what it came down to if the SDL_AUDIODRIVER was mismatched (broken) with the corresponding libsdl package, analog would be dead (debugs reported simply that the mixer could not be found), which then allowed direct attachment to the pcm device just fine. Which then begs the question, why is SDL binding the digital port when obviously it's only attaching to the analog channels in the first place? I can live without navigation sounds if it means my movies and music work, but this is a helluva bastard workaround for an obvious long-term problem.

Playing with combinations of devices in the xbmc config did little to nothing to help, SDL seems to be the problem here.

So that got me to looking into wtf the code is doing, and it seems the AudioContext lib is the primary issue. I'm not much of a dev, but if I'm following what is going on, it's making the decision for whether passthrough devices get used or not, but what is odd is that it's still trying to use "DSSPEAKER_USE_DEFAULT" vs. a specific device context, ie specifically the iec958 port, and preferably directly to alsa. This seems to me problematic, especially since SDL doesn't seem capable of properly switching between multichannel sound and pcm digital streams.

Wouldn't it make more sense to rather attach to the configured device directly as configured in xbmc vs. probing SDL to figure out how to use that port? Reading about SDL, it seems to just be an api layer to talk to ESD, which, then talks to pulse (everything ubuntu seems directed at pulse by default), then to alsa? Attaching directly to alsa seems to work just fine, and it seems it might be needed to end-around on these blasted SDL issues.

I could be completely off-base, which is why I'm nagging the guys that wrote the code, as they're probably more in touch with the challenges they face than I am. I just know I've been struggling with this for close to a year to make it work, but nothing userland is capable of fixing it so it seems. I'm not the only one having the issue either, infact sound seems to be the biggest hurdle for linux users, so there's got to be a better way.
Reply
#10
I found that a way is to disable audio output on multiple devices with pulseaudio
you can disable that in the pulseaudio manager
then the passthrough is available
Reply
#11
I have a very similar problem. I can play files fine in Gnome. When I first load XBMC I get navigation sounds. If I try and play a music file, I get the "Failed to initialize audio" error. If I try and play the file again, it plays successfully. If I try and play a different file, it fails again, but will work on the second attempt.

I am using the Jaunty SVN, on x64:
Code:
deb [url]http://ppa.launchpad.net/team-xbmc-svn/ppa/ubuntu/[/url] jaunty main
Code:
Linux mercury 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux

I have done a compare of the log file for a success and a fail. there are some differences

For the Failed attempt:
Code:
DEBUG: SDLKeyboard: scancode: 36, sym: 13, unicode: 13, modifier: 0
DEBUG: OnKey: 61453 pressed, action is 7
DEBUG: Shuffle shuffling at pos:0
DEBUG: new file set audiostream:0
DEBUG: CPlayerCoreFactory::GetPlayers(/home/user/Music/test.mp3)
DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: system rules
DEBUG: CPlayerSelectionRule::GetPlayers: matches rule: system rules
DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: rtv
DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: hdhomerun/myth/rtmp/mms/udp
DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: lastfm/shout
DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: rtsp
DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: streams
DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: dvd
DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: dvdfile
DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: dvdimage
DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: sdp/asf
DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: nsv
DEBUG: CPlayerCoreFactory::GetPlayers: matched 0 rules with players
DEBUG: CPlayerCoreFactory::GetPlayers: adding audiodefaultplayer (3)
DEBUG: CPlayerCoreFactory::GetPlayers: for video=0, audio=1
DEBUG: CPlayerCoreFactory::GetPlayers: adding player: PAPlayer (3)
DEBUG: CPlayerCoreFactory::GetPlayers: for video=1, audio=1
DEBUG: CPlayerCoreFactory::GetPlayers: adding player: DVDPlayer (1)
DEBUG: CPlayerCoreFactory::GetPlayers: added 2 players
DEBUG: SECTION:LoadDLL(special://xbmc/system/players/paplayer/MACDll-x86_64-linux.so)
DEBUG: Loading: /usr/share/xbmc/system/players/paplayer/MACDll-x86_64-linux.so
DEBUG: CFileCache::Open - opening </home/user/Music/test.mp3> using cache
DEBUG: thread start, auto delete: 0
INFO: PAPlayer: Queuing next file /home/user/Music/test.mp3
DEBUG: PAPlayer: Creating new audio renderer
DEBUG: PulseAudio: Opening Channels: 2 - SampleRate: 44100 - SampleBit: 16 - Resample false - Codec  - IsMusic true - IsPassthrough false - audioHost: default - audioDevice: custom
DEBUG: PulseAudio: Context ready
DEBUG: PulseAudio: Stream failed
ERROR: PulseAudio: Waited for the stream but it failed
DEBUG: CALSADirectSound::CALSADirectSound - Channels: 2 - SampleRate: 44100 - SampleBit: 16 - Resample false - Codec  - IsMusic true - IsPassthrough false - audioDevice: surround51
DEBUG: Initialize - using alsa device surround51
ERROR: Initialize - device surround51 busy retrying...
INFO: AudioDecoder: File is queued
ERROR: Initialize - pcm_open_lconf, alsa error: -16 - Device or resource busy
ERROR: Creating a Null Audio Renderer, Check your audio settings as this should not happen
DEBUG: OnPlayBackStarted - Playback has started
DEBUG: CGUIInfoManager::SetCurrentSong(/home/user/Music/test.mp3)
DEBUG: Loading additional tag info for file /home/user/Music/test.mp3
DEBUG: Starting Crossfade - resuming stream 0
DEBUG: OnPlayBackStarted - Playback has started
DEBUG: SaveFileState - Saving file state for audio file /home/rich/Music/Afro Cuban All Stars/A Toda Cuba Le Gusta/03 - Habana Del Este.mp3
DEBUG: ------ Window Init (DialogKaiToast.xml) ------
DEBUG: Alloc resources: 0.01ms (0.00 ms skin load)
DEBUG: CGUIInfoManager::SetCurrentSong(/home/user/Music/test.mp3)
DEBUG: Loading additional tag info for file /home/user/Music/test.mp3
DEBUG: Finished Crossfading
DEBUG: Thread 140205811329360 terminating

and for the Success:
Code:
DEBUG: SDLKeyboard: scancode: 36, sym: 13, unicode: 13, modifier: 0
DEBUG: OnKey: 61453 pressed, action is 7
DEBUG: Shuffle shuffling at pos:0
DEBUG: new file set audiostream:0
DEBUG: CPlayerCoreFactory::GetPlayers(/home/user/Music/test.mp3)
DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: system rules
DEBUG: CPlayerSelectionRule::GetPlayers: matches rule: system rules
DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: rtv
DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: hdhomerun/myth/rtmp/mms/udp
DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: lastfm/shout
DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: rtsp
DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: streams
DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: dvd
DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: dvdfile
DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: dvdimage
DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: sdp/asf
DEBUG: CPlayerSelectionRule::GetPlayers: considering rule: nsv
DEBUG: CPlayerCoreFactory::GetPlayers: matched 0 rules with players
DEBUG: CPlayerCoreFactory::GetPlayers: adding audiodefaultplayer (3)
DEBUG: CPlayerCoreFactory::GetPlayers: for video=0, audio=1
DEBUG: CPlayerCoreFactory::GetPlayers: adding player: PAPlayer (3)
DEBUG: CPlayerCoreFactory::GetPlayers: for video=1, audio=1
DEBUG: CPlayerCoreFactory::GetPlayers: adding player: DVDPlayer (1)
DEBUG: CPlayerCoreFactory::GetPlayers: added 2 players
DEBUG: CFileCache::Open - opening </home/user/Music/test.mp3> using cache
DEBUG: thread start, auto delete: 0
INFO: PAPlayer: Queuing next file /home/user/Music/test.mp3
DEBUG: PAPlayer: Creating new audio renderer
DEBUG: PulseAudio: Opening Channels: 2 - SampleRate: 44100 - SampleBit: 16 - Resample false - Codec  - IsMusic true - IsPassthrough false - audioHost: default - audioDevice: custom
DEBUG: PulseAudio: Context ready
DEBUG: PulseAudio: Stream failed
ERROR: PulseAudio: Waited for the stream but it failed
DEBUG: CALSADirectSound::CALSADirectSound - Channels: 2 - SampleRate: 44100 - SampleBit: 16 - Resample false - Codec  - IsMusic true - IsPassthrough false - audioDevice: surround51
DEBUG: Initialize - using alsa device surround51
DEBUG: CALSADirectSound::Initialize - packet size:2048, packet count:10, buffer size:5120
12:38:55 T:140206082730048 M:666832896 WARNING: CALSADirectSound::CALSADirectSound - requested samplerate (44100) not supported by hardware, using 48000 instead
INFO: AudioDecoder: File is queued
DEBUG: OnPlayBackStarted - Playback has started
DEBUG: CGUIInfoManager::SetCurrentSong(/home/user/Music/test.mp3)
DEBUG: Loading additional tag info for file /home/user/Music/test.mp3
DEBUG: Starting Crossfade - resuming stream 1
DEBUG: OnPlayBackStarted - Playback has started
DEBUG: CGUIInfoManager::SetCurrentSong(/home/user/Music/test.mp3)
DEBUG: Loading additional tag info for file /home/user/Music/test.mp3
DEBUG: Finished Crossfading
DEBUG: Thread 140205777758544 terminating
DEBUG: SECTION:UnloadDelayed(DLL: special://xbmc/system/libid3tag-x86_64-linux.so)
DEBUG: Unloading: libid3tag-x86_64-linux.so
DEBUG: SECTION:UnloadDelayed(DLL: special://xbmc/system/players/paplayer/MACDll-x86_64-linux.so)
DEBUG: Unloading: MACDll-x86_64-linux.so

The Primary things I notice are the MACDll-x86_64-linux.so loads on the failed attempt, but not on the success.

The other is the message:
ERROR: Initialize - pcm_open_lconf, alsa error: -16 - Device or resource busy on the failed attempt.

The stable version did not do this. I upgraded to the SVN version because of the web interface problems on the 9.04 version, under 64bit Linux. The web now works, but the audio is misbehaving.

Any suggestions would be greatly appreciated. I would love to get it working, as this looks like a fantastic piece of software.
Reply
#12
SlyOne, please use pastebin.com for your logfiles. Also, please post only complete logfiles, no snippets. Have a look at my signature on how to submit a proper problem report.

Cheers!
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply

Logout Mark Read Team Forum Stats Members Help
PulseAudio coexistance with XBMC?0