[Openal-devel] Patch for intermittent ALSA capture
chris.kcat at gmail.com
Tue May 6 17:25:40 PDT 2008
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
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.
More information about the Openal-devel