[Openal-devel] Patch for intermittent ALSA capture

[Chris Robinson]

On Tuesday 06 May 2008 04:44:03 pm Jason Daly wrote:
> No problem.  Any chance you'll make a new release soon?

I could, though there's been a grand total of six patches since the release..

> My main concern is to get OpenAL-Soft out to the distributions.  I think
> we're mainly waiting on the new Creative web site for this, though.

>From what I hear, Debian's close to getting it officially packaged. Gentoo has 
an active bug for an OpenAL Soft package. The main concern is what it'll 
break. Problem being that the lib has a different name (libopenal.so.1 
instead of .0), so apps built for the SI won't directly work with ALSoft and 
vice versa, though source distros like Gentoo have an easier time there.

There's also the issue of missing extensions, like AL_EXT_vorbis that some 
apps have used, and apps that relied on undefined/improper behavior.. and you 
get people concerned that apps won't work without being fixed (and with some 
of the apps being unmaintained..).

It'll eventuially get there though, when more apps are buggy/unusable with the 
SI instead of with ALSoft.

> > But on the subject of what to do with OpenAL Soft, I've been wondering
> > about splitting out the main mixer so that it runs in a seperate process,
> > and using IPC and shared memory so that multiple apps can use a unique
> > context on the same device (so, for example, a media player can open a
> > device with openal soft, get a context and turn off the uneeded features
> > for faster processing, while a game has that same device open with 3d
> > audio + effects, all being mixed and output into one ALSA/OSS device).
> > I'm not too sure of how efficient I could get a setup like that working,
> > though..
>
> This might be useful (I've run into that problem here, albeit rarely).
> I'm a bit surprised that it didn't just work through dmix, though (maybe
> I don't understand dmix well enough).

I don't have any issues with ALSA using dmix, though I've noticed ALSA can be 
picky about just how dmix is used (despite saying dmix is on by default, 
opening 'default' always grabs a hw:x,y voice, unless explicitly overridden 
with ~/.asoundrc).

The main thing, though, is with apps that may want to use an out-of-process 
app for additional audio (like mplayer to play background music or a video 
cutscene that contains audio), without fighting over the soundcard. And of 
course, with 3D accelerated desktops around, why not get some 3D audio in 
with them? It would also help since you can then renice the mixer process 
independant of the app(s), and let OpenAL mix right to a hardware voice 
(since running a software mixer on a software mixer is kind of ugly), while 
not blocking other apps that use OpenAL.

I'm just not sure how I could get it working efficiently, without making AL 
calls stall all the time as they need to perform some IPC or global locks.