[ut2004] ALSA sound without OSS emulation

[Zephaniah E. Hull]

On Sun, Mar 21, 2004 at 11:56:09PM -0600, Alex Malinovich wrote:
> On Thu, 2004-03-18 at 19:35, Ryan C. Gordon wrote:
> > > Correct, it's the retail version.
> > >
> > > Can you tell me more about what order UT searches for audio devices in?
> > > I'm using udev, so devices get created as needed. If UT is checking for
> > > a device that hasn't been automatically created by udev, it's possible
> > > that it thinks that ALSA isn't enabled and is therefore going back to
> > > OSS support.
> > 
> > I believe it tries them in the order your .openalrc file requests, and
> > ALSA can fail if the libraries don't load or (inside libasound) it can't
> > open the device. I don't know what libasound does behind the scenes.
> 
> While this is certainly a rather substantial claim on my part, I'm
> beginning to think that openal requires OSS support in ALSA. I had
> thought that it was a misconfiguration on my desktop that was causing
> the problems. Something between the combination of a 2.6 kernel, udev,
> etc. So I decided to test it out on my laptop.

Strong data point, while I have the OSS emulation compiled in and thus
can not actually verify that it works without it completely, I /CAN/
verify that starting ut2004 on my system never attempts to open /dev/dsp
or /dev/sound/dsp.

I will however note that if for any reason the alsa output module of
openal fails, it will silently fall back to OSS.

I would strongly suggest checking to make sure that the user trying to
run this can use other ALSA applications, such as alsamixer and some
sound player with an ALSA output backend.

I do think that OpenAL should yell a little louder when it fails to use
the requested backend though, I'll take a look at making it do that, but
I make no promises.

-- 
	1024D/E65A7801 Zephaniah E. Hull <warp at babylon.d2dc.net>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

"I would rather spend 10 hours reading someone else's source code than
10 minutes listening to Musak waiting for technical support which
isn't."
(By Dr. Greg Wettstein, Roger Maris Cancer Center)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://icculus.org/pipermail/ut2004/attachments/20040322/2a93a98e/attachment.pgp>