[sldev] [VWR] openAL wind generator WIP

[Kamilion]

Might I suggest PulseAudio?
Most of the large binary distros are or have moved over to it.
http://www.pulseaudio.org/
https://blueprints.launchpad.net/ubuntu/+spec/cleanup-audio-jumble
https://wiki.ubuntu.com/DesktopTeam/Specs/CleanupAudioJumble
FC8's already got it. Ubuntu 8.04 Hardy already has it as well.

Summary
The idea is to make PulseAudio the default sound system on Ubuntu,
replacing the Esound Sound Daemon (esd) and ALSA dmix. PulseAudio is a
drop-in replacement for Esound, but adds new features, opening it for
many entirely new areas.

Rationale
Apple managed to standardize on a single powerful sound system
(CoreAudio) for MacOSX which makes almost all users happy, ranging
from normal day-to-day desktop users to gamers, to professional audio
people. We should be able to provide the same on Linux. PulseAudio can
currently provide the functionality at least partially, with the only
notable exception being pro audio. PulseAudio is a modular sound
server, kind of an "application server" for audio. Beyond the obvious
sound mixing functionality it offers advanced audio features like
"desktop bling", hot-plug support, transparent network audio, hot
moving of playback streams between audio devices, separate volume
adjustments for all playback or record streams, very low latency, very
precise latency estimation (even over the network), a modern zero-copy
memory management, a wide range of extension modules, availability for
many operating systems, and compatibility with 90% of all currently
available audio applications for Linux in one way or another.

------------

Pulse is very modular. VERY modular. It can talk to nearly anything.
Takes input/output from ALSA, OSS, Jack, aRts, ESD, RTP, A2DP, OpenAL, dmix.
So far the only known application with real problem is the skype linux binaries.

Applications can take full advantage of pulse by using libpulse0.

An example to split a four-channel "surround" sound card to two
virtual stereo cards (the first virtual card doesn't really do
anything else than limit all streams to two channels, so it's not
essential to have):

#hw
load-module module-alsa-sink sink_name=alsa_out device=hw:0 channels=4
channel_map=front-left,front-right,rear-left,rear-right
#virtual
load-module module-remap-sink sink_name=front_stereo master=alsa_out
channels=2 master_channel_map=front-left,front-right
channel_map=front-left,front-right
load-module module-remap-sink sink_name=rear_stereo master=alsa_out
channels=2 master_channel_map=rear-left,rear-right
channel_map=front-left,front-right

I happen to like this example: On my main linux box (nforce2), the
onboard audio is connected to my desktop speakers on the front
channel, and the stereo in the living room on the back channel.
I can have TV playing on the front channel, and play music from my
laptop over the network on the back channel to the stereo. It even
stays in sync with the speakers on the laptop -- compensation for
network lag. The laptop plays shoutcast through Rhythmbox over wifi to
it's local pulseaudio daemon, which forwards it over RTP to the main
linux box in the living room, and the remote pulseaudio daemon pipes
it to the rear channel via ALSA. Channels can be broken apart and
recombined. For instance: Split your surround sound's center channel
out, and bridge SL's output to it from another computer. And since
it's a sink/source system, other computers on the LAN can link in to
either the sink or the source directly. Pidgin could also be prodded
to provide it's IM ding to the same channels. We all have different
incoming IM sounds here -- but they are *all* piped to three rooms of
the house. Living room, kitchen, office. No matter where any of us are
we are capable of knowing which of us have an IM, a skype call, or
*someone*'s SL session. (that last one's the hard part, since it's
"dingding!" for everyone...;)

PulseAudio will always accept audio, and supports failover.
Say you're using SL, and the audio is going to your USB headset. You
lean back in your chair, and the usb cable pops out. With pulseaudio,
it just pops the stream over to the last device it was on (if it had
one) or to the default device (usually onboard audio), or to the
network sink (which is ALWAYS available) until you plug the USB cable
back in, and then it returns the stream to the USB headset.

Without pulse, SL would have crashed when udev removed the device
nodes. (it does on windows and linux! Always fmod barfing.)


On Jan 14, 2008 8:29 AM, Dzonatas <dzonatas at dzonux.net> wrote:
> Carsten Juttner wrote:
> > Hm, could you elaborate on this a bit? OpenAL has several audio
> > backends including ALSA. I use the dmix plugin-in to be able to open
> > ALSA from several sources and it works fine.
>
> We need to document the best way.  I started to look into JACK, but
> there is little documentation. It's mainly how nicely sound concurrency
> works between several apps. Some apps, like Gnome, want to use ESD.
> Skype wants to use some form of /dev/dsp (ESD or OSS). Icedove wants to
> use /dev/dsp or ALSA. OpenAL I have set to try to use ALSA, aRts, ESD,
> OSS, or none. Etc...
>
> There is no up-to-date how-to on the best way to get these all to work
> nicely. One app wants steal the sound and another app hangs or crashes.
> It doesn't all work out of the box.
>
> If all other sound drives fail to open, I did get OpenAL to use the null
> device instead of fail to let slviewer continue to run:
>
> ~/.openalrc:
> (define devices '(alsa native arts esd null))
> (define alsa-device "default")
> (define speaker-num 2)
> (define sampling-rate 44100)
>
> I thought dmix was only needed if the sound card doesn't support a
> hardware mixer, so I opted to try to figure out JACK, but there is
> little documentation.

Yeah, dmix is only *needed* for hwmixerless cards, but it will mix
anything you feed it and it's widely installed.