Linux n00b; stuttering sound under OpenSUSE 10.2

Hello!

I'm having "stuttering" sound in the SL client. I was hoping the newest version would fix that, but it hasn't. I've tried uncommenting the lines in the launch script, but that doesn't help, although I can make the sound go away completely.

Unfortunately, my Linux knowledge is woefully lacking, and that's about all the information I can give you about the problem now. If you need to know more about my setup, please tell me how to find the information you need.

I'm sorry I can't be more clear.

Do you mean all sounds, or particularly streaming music? I get terrible quality from the media stream, but regular sounds play fine..

All sounds.

You might also describe the effect as "choppy". To be more specific, it sounds like the sound is being interrupted--turned on and off--at regular and rapid intervals, as though you were trying to listen through a fan or something. No other program does this.

This is a problem with dmix that is extremely common.

Most people who use Linux are running with ALSA at the lowest layer of the stack. Right now, the only reliable way to get quality sound on top of ALSA is to use PulseAudio or esound. I highly recommend PulseAudio which, while slightly more tricky to configure than esound, is newer, more supported, and has lower latency. It also has an esound compatibility mode, which is what you can use for SL.

SL directly uses one of three sound APIs through fmod:
1. OSS
2. ALSA
3. esound.

As you can see from http://blogs.adobe.com/penguin.swf/2007/05/welcome_to_the_jungle.html there are many ways to convert one sound API into another. Not surprisingly, the higher the number of indirections from the lowest layer, the less likely it is to work, and the more latency you'll incur.

For example, it is possible to (starting from the ALSA kernel modules interfacing directly with the hardware) do something like:

ALSA kernel --> ALSA library --> JACK sound server --> PulseAudio sound server --> OSS emulation on top of pulse --> Second Life, to allow SL a (very faint) chance to play sound using the OSS API.

Right now, your distro is probably doing something like this :

ALSA kernel --> ALSA library (dmix) --> Second Life, meaning SL is using its ALSA mode.

I find that SL's support for ALSA, as an API, is completely broken. It has been for many, many, many releases.

This leaves us with two alternative APIs: eSound, and OSS. Now, most sound servers out there offer some sort of direct OSS emulation; indeed, even alsa-lib offers direct OSS emulation. But the fact is, each of these only works with a few applications they were written to support, and fail horribly on the majority of applications, with little overlap.

The best way to enable applications using the OSS API is to use 4-Front Technologies' open sourced, GPLv2'ed, OSS/4.0, which is a complete kernel-mode, user-mode and software mixing solution that is Free Software. The OSS/4.0 distribution works perfectly with SL when SL is using the OSS API. Note that while OSS/4.0 does offer partial user-land compatibility with alsa-lib (the ALSA library), your ALSA kernel modules can not be loaded at the same time as the OSS kernel modules. This may require you to move away from using applications that support only ALSA, or to investigate other alternatives (like running PulseAudio on top of OSS, and then enabling the PulseAudio plugin for alsa-lib to allow ALSA-lib clients to work.)

If you are too afraid to mess with your kernel, then I recommend instead that you simply install PulseAudio, and have it use your ALSA system as its backend. So your audio path would then be:

ALSA (kernel-mode) --> alsa-lib (user-mode) --> PulseAudio sound server's built-in eSound protocol support --> SL Client running in eSound mode.

There are threads here detailing just about every viable setup, but either esound or pulseaudio is a very popular solution.

If you don't like the quality of SL's sound support, complain to Linden Labs. They are using the FMOD sound engine, which has a very myopic view of the Linux sound jungle, much like almost every proprietary application. The GStreamer media framework is perfectly capable of doing everything FMOD does in relation to SL, and GStreamer's support for ALSA (including dmix) is flawless, and would work with most distributions "out of the box". Not to mention GStreamer is also Free Software.

HTH,

-Tiyuk (Hi Stahl, ltns!)

That was a useful writeup, thank you.

Are the open-source client hackers working on complete removal of the unnecessary (and closed) FMOD layer? It's been a thorn in my side for ages anyway, as I work on a 64-bit Linux box and the fmod-3.75 people can't even be bothered to compile a 64-bit version for us.

Since gstreamer is now a dependency for streaming video, things seem to be heading in a sensible direction, but is removal of FMOD actually on the joblist?

Morg.

That was a useful writeup, thank you, and the snippet above was interesting.

Are the open-source client hackers working on complete removal of the unnecessary (and closed) FMOD layer? It's been a thorn in my side for ages anyway, as I work on a 64-bit Linux box and the fmod-3.75 people can't even be bothered to compile a 64-bit version for us.

Since gstreamer is now a dependency for streaming video, things seem to be heading in a sensible direction, but is removal of FMOD actually on the joblist?

Morg.

FMOD historically doesn't like to play nice on 64bit systems, or linux in general, the Alsa support is quite broken often breaking in the first one or two sounds played.

Another important note is that OSS is being removed from the linux kernel in the next release or two in favor of Alsa. So if things stay as they are the only way for sound to work for a linux user will be for them to use a sound server. Sound servers may be ok on dual core or high end systems but under heavy cpu load they will lag the sound.


Gstreamer might be an option but someone will have to replace FMOD and merge in gstreamer.

Gstreamer can't do the spatial audio and Doppler stuff, so removing fmod will have to wait until OpenAL is merged.

Is there info on plans/timeline for the client? It'd be nice to know what directions this is doing to head in. Folks might help with the main client instead of branching off on their own.

At least gstreamer is already merged for the video streaming and its audio component, so we're part of the way there. Loss of spatial and Doppler audio would be a small price to pay for most of those of us who run open-source 64-bit systems and need sound now. Just mix the 6 audio input streams as currently, and leave the spatial processing as a dummy DSP module for implementation with OpenAL later.

Morg.

It goes deeper than that.

The work of the Architecture Working Group will require major changes in the client too, yet the AWG is not involved in client work. This means that there needs to be an official LL+community group set up in the client sphere as well, to tie in with our infrastructure work. We need to talk to you.

The whole area of client development needs to be put on a more solid (and open) footing, to match server-side evolution.

Morg.

All handy stuff, and thanks for the info. But I do wonder why they keep the broken ALSA support in the client at all!
Has it ever worked for anyone?

Not so fast. First of all, if we go to OpenAL, its ALSA support is pretty good (it's as good as ALSA support can be expected to be.) Second, I don't think OSS is going away so quickly. Here are some reasons:

1. The OSS API is de facto. There are currently more applications on *NIX platforms that support OSS than any other single API for handling PCM data. Even very new Linux-targeted apps often support OSS.

2. 4Front Technologies has open sourced their entire OSS/4.0 implementation. Currently they claim that, if you download a binary release straight from them, it has one or two additional drivers/tweaks that are currently not available in OSS/4.0 due to third-party licensing, but that this should be rectified in the next major release.

3. While ALSA-lib is often seen as needlessly complex, the OSS API by contrast is a minimal set of widely UNIX-compatible routines and syscalls. It accomplishes the same task as alsa-lib, without requiring programmers to learn the semantics of hundreds of functions. Because of its straightforwardness, most OSS client applications simply "just work". By contrast, ALSA applications are extremely error-prone: your success with ALSA depends on what kind of plugin chain you're using.

4. With enough community support, the license of OSS/4.x is GPLv2 and thus compatible with the Linux kernel. It could be that some day the 4Front Technologies implementation of OSS is put into the mainline kernel.

5. The current mainline kernel version of OSS is not a modern, robust OSS implementation. Most of its problems are at the driver layer rather than at the API layer. For example, it has very limited hardware support, and has no support for software mixing. 4Front's implementation corrects this on both accounts.

6. There are numerous ways to use ALSA-only apps with OSS/4.x in the kernel. So even if ALSA continues to snowball in popularity in the developer community, OSS/4.x is not out of the question as your lowest layer choice.

Of course, OSS/4.x is not perfect. Here are some things that need to be improved:
1. Although its hardware support includes cards not supported by ALSA, ALSA supports many cards not supported by OSS. "Supports", here, is used loosely as "there is a driver that's supposed to work with card X".

2. OSS/4.x uses the "vmix" kernel module for software mixing. This causes about 500 wakeups per second by design, so it is significantly suboptimal for power consumption with laptops on battery. On the other hand, most other software mixing solutions (including PulseAudio) are also very hyper on wakeups (but I don't have a rigorous comparison available).

3. Currently there are few applications capable of understanding the OSS/4.x mixer, even if they support the OSS API. If you want to change your volume, the only (really) useful way of doing it is with the bundled "ossxmix" application. This app is itself very confusing and takes some trial and error to understand its workings.


Actually, the only true sound server that *does not* add latency to the sound is JACK. JACK has its own compatibility issues, and there are currently many reasons not to use it.

If you are referring to eSound/PulseAudio, that is not CPU speed you're noticing, that is the size of buffer that these sound servers use. Even a 768-core data processing machine will not have better latency (lag) with eSound/PulseAudio than, say, a single-core Pentium 4. These sound servers intentionally focus on compatibility and low CPU usage in exchange for a large sound buffer. The larger the buffer, the longer it takes for sound updates to get through to the sound card.


There will always be a few people who complain about the spatial audio and doppler support. Personally I have absolutely no need for these anti-features, which seem to have been defined with proprietary technology in mind.

However, OpenAL seems like a promising solution. It doesn't have the robust codec support and plugin extensibility that GStreamer does, but it has the raw PCM technology that SL currently needs to maintain its sound functionality. So we might end up using both OpenAL and GStreamer. Other than increasing the number of dependencies, I can't see a good reason NOT to replace FMOD with OpenAL. The difficulty is in the merge itself, because the APIs don't match up one to one.

This is a great point. It's alarming that the client technology receives so little attention. Everyone seems to think it's "not my job" to maintain the client. But without a full-featured client, SL has little use. Maybe you should try to push for a working group for the client. It seems that Linden needs particular "help" and "steering" to understand that proprietary solutions aren't the way to go.

Supposedly, you should be able to use it if you:
1. (A) have a sound card with hardware mixing, or
(B) close all other apps using sound except Second Life

AND

2. set up ALSA to map the "default" device to
pcm.!default {
type plug
slave.pcm "hw:0"
}

If this most basic support does not work for you, then yes, FMOD 3.75's ALSA support is _totally broken_. Personally I use OSS/4.x so I am unable to test the case of opening the ALSA "hw:0" device.

However, whenever I see a proprietary application that supports ALSA, I immediately have a strong suspicion that they have only tested (and perhaps hard-coded) their application to work with the hw:0 device. This is a terrible error and a failure to understand the dynamic nature of ALSA, but nonetheless it is a common error, propagated by Adobe, RealNetworks, TeamSpeak, and Skype until very recently. I consider "the hw:0 test" as a sort of base case: if sound does not work under the above circumstances, then the application or library in question is considered (by me) to be 100% ALSA-incompatible.

Hey neat trick! Using that I can get second life to run with ALSA although it then blocks anything else from using the sound card. Guess I don't have hardware mixing, and I didn't test it for long since my current ESD -> aRts workaround is reliable enough and allows multiplexing. Thanks for the tip though!

Update: Um then Secondlife never seems to release ALSA after I quit it, so I can't use other sound apps until I restart a bunch of things. Thinks. Am gonna call that broken!

In 2.6.x OSS is no longer the default sound system, it's come up on http://lkml.org/ a few times about the potential removal of OSS from the kernel with a compatible alsa interface merged in. It was supposed to be in 2.6 from the start but it is still coming along.

FMOD and gstreamer are different things yes, but interfacing to the system should be done through gstreamer, with either FMOD or OpenAL backing that. OpenAL would likely be a lot better choice in that. This would be to the benefit of all since every common linux desktop system comes with working gstreamer.

One of the largest problems with OSS sound card sharing and the use of a sound server. Why has linux been suffering from a problem that was solved in Windows 95? An application shouldn't get total control of the sound device. OSS often does work with little or no configuration, but only one application at a time unless someone wants a sound server which is going to eat up resources when competing against a game application.

The problem is that users here are getting sub par sound, the OSS offering works but blocks other applications, I care not about OSS history, it is important that the linux kernel is moving towards ALSA.

The next question is, has anyone configured a script for .asound which allows OSS sharing of a sound card without the use of a sound server? How about an .asoundconf file for ALSA sharing of the sound device when OSS is used for SL sound?

Would the posting of these files be helpful?

Certainly would! Trouble is from the little digging I've started, you seem to need a different .asoundrc file depending on the type of soundcard you have. Might keep digging though!
Intrepid readers may want to start here http://gentoo-wiki.com/HOWTO_ALSA_sound_mixer_aka_dmix