Pulseaudio problem with intrepid Ibex

I upgraded my ubuntu to Intrepid and voice chat quit working.

It gives this error:

AL lib: pulseaudio.c:599: alcPulseAudioInit
terminate called after throwing an instance of 'std:ut_of_range'
what(): basic_string:ubstr


pulse works with every other program

PulseAudio is not compatible with SL without serious knowledge of PulseAudio. If you don't know how to reconfigure pulse on a fairly low level, you're better off switching to a distribution such as Debian that does not install PulseAudio by default. This is the recommended fix.

If you do know what you're doing with Pulse, you might be able to tweak it to do what you want; you might not. Consult the SL Wiki's Linux voice page and the PulseAudio documentation for more details on this. This will break every time you upgrade your SL viewer or breathe on PulseAudio wrong.

Good luck!

I found that if i was on skype i wouldn't hear audio from SL, so this was the answer for me

sudo apt-get install esound (PC / Laptop restart needed)

It all worked 100% and i can use both, I am guessing this fix will also work on 8.10.

Up to you if you wish to use my fix, or tweak the Pulse audio files

I had a bad out-of-the-virtual-box experience with KUbuntu 8.10, in which small things were very broken and would just annoy me to no end. Switching to Xubuntu 8.10 worked out for me. I'll check to see if PulseAudio is on Xubuntu, and then see about getting SL working on this Asus EeePC 900A.

I tried installing esound in 8.10, even removed everything for pulse, and still no luck. Are there any additional steps to be taken?

all i did was just sudo apt-get install esound, it removed the pulse file and worked for me

To make PulseAudio work, changes have to be made to most or all programs that use sound. If Pulse is installed by default, reversing this is very likely easier said than done. Using a distribution designed for general use (Debian for sure, or likely one of the other relatively complete distributions) instead of being specialized to be a corporate desktop (Xandros, *buntu, etc) will generally avoid the problem altogether.

Also, Linden Labs uses Debian on their Linux desktops and servers (http://www.debian.org/users/com/lindenlab), so it's probably no wonder more often than not SL works with voice out of the box on that distro.

Baloo, you need to stop distributing this FUD. Pulse is a drop-in replacement for applications that use ESound (it provides an implementation of the ESound server) and offers compatibility with other applications via its ALSA plugin. Thus, on a correctly configured machine with correctly behaving applications, PA /is/ a drop-in replacement for ESound and ALSA.

Some poorly written applications both don't support ESound and abuse the ALSA progamming interface (/me looks at Skype) and yes, these will have trouble with PA, but that is the application's fault and the number of applications in this category is very much the minority.

PA is not without bugs, and there is some question as to whether distros have started shipping it too early (i.e. before it was mature enough). However, they have and PA is certainly the way forward for the desktop linux sound. So get used to it.

To bring this back on topic, to get sound working on Intrepid or other distributions using PA, ensure you choose ESound wherever that is offered. If this is not possible, choose ALSA and make sure you have the PA ASLA plugin installed and /etc/asound.conf configured to use "pulse", as per other threads in this forum. If need be, uncomment the LL_BAD_OSS and LL_BAD_ALSA in your "secondlife" startup script.


/Get

Don't do this, it is a step backwards and will likely cause a number of other problems - having to organise the ESound daemon to start, losing non-broken simultaneous playback, getting playback glitches and not to mention that eventually ESound will disappear (it hasn't been actively worked on for years) so you'll need to get PulseAudio working sometime anyway.

/Get

If this were true, SL would work out of the box with PA's lacktastic esound emulation. It doesn't without major tweaking. If PA wants to claim esound support, they should actually support esound as well as esound. Otherwise get out of the way.

Tuomy, this looks like a problem with OpenAL, if so, the instructions here under "OpenALApplications" might help work-around the problem: http://www.pulseaudio.org/wiki/PerfectSetup#OpenALApplications.

/Get

It worked for me without any tweaking under Gutsy and now Intrepid. The only application that has ever been a problem is Skype, happily I don't have to use that any more.

/Get

You shouldn't be losing simultaneous playback unless your hardware doesn't support it. In which case, emulating such functionality in software is not the answer and simply takes CPU cycles away from what you want to use them for (SL). Sound devices that are capable of playing multiple streams in hardware are cheap these days, like under L$5000 (in your local first life currency) at Fried Electronics, Worst Buy...even my local Kroger grocery store!

With that kind of luck, you really wasted it by having PulseAudio work for you out of the box. If you bought a PowerBall ticket instead, you would be rich right now.

Depends on which variant of Ubuntu. Xubuntu does not install PA.

sorry I should google it on my own ... you mean that
Ubuntu 8.10 ships Pulse Audio - while Xubuntu 8.10 doesn't ??

That surprises me ... I thought that different Ubuntu flavors shared this kind of components...
...I think I'm going to install Xubuntu (already tried it, and liked it btw).

So what specific problems did you have getting an ESound compatible application working with Pulse Audio and precisely what tweaking did you need to do to fix it?

/Get

I removed pulseaudio entirely and just used esound instead. Pulse isn't an esound substitute despite it's claims to the contrary.

I see. So you have no actual first hand knowledge because you haven't even used it.

Can I suggest you stop talking about something you clearly have no idea about? There's too much static in the world already.

Thanks,
/Get

No, as in, pulseaudio didn't work at all in SL, I RTFM'd, still didn't work. I know what I'm talking about, please quit claiming PA is quality software and a drop in replacement for esound, when it's exactly the opposite.

Baloo, do you even use Linux? Do you have any familiarity whatsoever with how its sound daemons work? If not, then you really need to educate yourself before making comments like this that bring serious doubt as to your credibility in this arena.

As for SLVoice not working properly with PulseAudio being PA's fault, that's just straight-up wrong. SLVoice, and its hodgepodge of libraries, is not PA-aware; does not play nice with ALSA at all; and is not ESound-compliant. This means the only real possibility that's left to make it work is with OSS emulation - something that worked via padsp in Gutsy and Hardy, but now suddenly doesn't work under Intrepid.

Incidentally, FMOD - SL's main audio engine - works absolutely wonderfully with PulseAudio.

Yes, I've been using Linux as my primary operating system since 1997. I've long ago learned in Linux that if you want sound to work reliably, get hardware that does what you want. Adding levels of complexity in software is a great way to complicate your life. PulseAudio is a great example.



What's wrong with just using ALSA? There's a complete sound system in the kernel for a reason, people! ALSA's sound support works wonderfully without Pulse right out of the box anywhere, plus does all the fancy stuff in your sound hardware instead of wasting userspace cycles on it.



Meaning Pulse works in the most broken way possible. It's like they're trying to reproduce everything wrong with the Windows sound system on Linux.

I disagree. Pulseaudio may be a bit rough around the edges right now, but it does not add to the complexity. That complexity already exists with programs that work with one daemon but not another, so you end up having to have OSS and ALSA running concurrently. Throw in ESD and aRTS, and you've got yourself an unholy compatibility and portability mess! Pulseaudio is to be the answer to that, providing a client/server solution that intercepts all these various calls and pipes them through ALSA. So instead of having a myriad sound solutions creating compatibility issues, you can have one unified solution.

Not everything supports ALSA - SLVoice is a perfect example. Audacity is another prime example. ALSA also doesn't support multiple concurrent calls or software mixing, at least not without JACK.

ALSA hasn't gone away. Pulseaudio sits on top of ALSA and cleans up the multiple-API mess.

Anyways, the positives and negatives of Pulseaudio is not germane to this discussion. Love it or hate it, PA is here to stay and is coming soon to a distro near you, if it hasn't already; so instead of fixating on why Pulseaudio came to be, let's focus on why Second Life's sound interfaces are such an unholy mess, and why SLVoice is so broken even Pulseaudio can't properly track it!

ALSA is the wrong level for userland programs to use. In the same way X Windows manages userland access to your graphics hardware, Pulse Audio manages access to audio hardware. Pretend we're talking about graphics for a moment, this is essentially your argument:



Also, sound cards are tending towards not supporting simultaneous output because it's cheaper to do it in software. What if your media center pc's integrated sound doesn't support it? What if your notebook doesn't? Why should you be penalised in these cases?

/Get

ALSA has OSS support for backwards compatability, but you don't end up running both the old school OSS and the new school ALSA at the same time unless you're using a kernel that still includes real OSS and have two sound devices, one supported only in OSS, the other only in ALSA. Kernel level is layer 0, and most everything is happy to work with the kernel's sound alone (including Second Life with SLVoice).

9 times out of 10, you have someone with pulseaudio, a userspace daemon that depends on the kernel's sound support itself, is having a problem. Having anything additional to the kernel IS extra complexity. And since the only thing PA buys you that the kernel doesn't have already if your sound device is up to snuff is networked audio. Do you really need networked audio? No? Then PA is, by definition, an extra needless level of complexity when it comes to setting up sound. Prospero Linden was on the Linux Client Users group chat in world yesterday saying exactly that as well.



Strangely enough, that's what the kernel provides. I mean, all of the sound daemons eventually output to ALSA, so how is that not



SLVoice does work on ALSA, out of the box even. Feel free to give me a call inworld and I'll prove it to you. Your audio hardware must support multiple sound streams for it to work, though. This isn't an ALSA limitation, it's a hardware limitation. If your sound device can only play one stream, of course you're only going to be able to have one program use it at a time.



Which shouldn't have existed in the first place, since ALSA is itself THE sound API for Linux these days. The only thing sound daemons buy you is networked audio and to gloss over the limitations of shitty hardware by stealing cycles off the CPU.



The general feeling at least with Debian reading the mailing lists isn't that unlike my own: We're not clueless about audio, and we're a little fed up with other distros causing problems with newer users by giving them a difficult, needlessly complex sound system when it gives them zero functionality they'll actually used. How many new Linux users actually use networked sound?