<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Chris Robinson wrote:<br>
<blockquote cite="mid200803171525.25678.chris.kcat@gmail.com"
type="cite">
<pre wrap=""><!---->
But it's a very app-specific setting. If you have a circular speaker setup
with a radius of 10 feet, for example, and have a source that's 10 feet away
from the listener, it should only play on the two speakers it would be
closest to (and as it moves closer, it would use more speakers to envelop the
listener and give the effect that the source is inside the field, as opposed
to on the edge of it).
</pre>
</blockquote>
<br>
Right. What is app-specific about that? To me, it seems more of a
"site" configuration (handled by implementation-level parameters) than
an app configuration. If a user has a particular audio hardware
configuration, why should he have to configure every OpenAL application
he uses to match it? Doesn't that belong in the implementation
settings?<br>
<br>
I agree that it would be nice to have a way to query it and make use of
it, but it shouldn't have to be set each time.<br>
<br>
<br>
<blockquote cite="mid200803171525.25678.chris.kcat@gmail.com"
type="cite">
<pre wrap="">The problem is.. what's 10 feet in an OpenAL program? OpenAL is designed to be
very agnositic with respect to real-world-to-unit sizes (ie. a unit is a
unit; there is no correlation to inches or feet, and its up to the app to
determine how much space a unit covers). A blanket implementation
configuration setting may work for one app, but another app could use a
different scale.
</pre>
</blockquote>
<br>
Personally, I've never really understood the desire to keep OpenAL
unit-agnostic. If you're trying to model a virtual acoustic
environment, you're going to need to know real distances at some point
(it pops up time and time again, this is just another time).<br>
<br>
The speed of sound parameter points in this direction, but that's only
used for Doppler so far.<br>
<br>
I know keeping units out is important to some people, so I don't press
it too much, but to me, it would be a lot simpler to just say "these
are the units."<br>
<br>
But, I digress...<br>
<br>
The implementation would know what units the speaker settings are in
(Creative's configuration utility happens to use feet). When the
application goes to query them, it would have to know what those units
are as well. There really isn't a way around that that I can see.<br>
<br>
<br>
<blockquote cite="mid200803171525.25678.chris.kcat@gmail.com"
type="cite">
<pre wrap="">My idea would be to use the min/reference distance of a source to specify the
listener's radius. An app would have a configuration setting for the number
of feet in the user's speaker setup, and would translate that to its own unit
scale to apply to generated sources (a context attribute wouldn't work since
those are only integers). Of course, this means apps would have to be aware
of it for it to work correctly.
</pre>
</blockquote>
<br>
Yeah, I thought of this too. It seems a natural way to handle it, but
it does put an extra burden on the developer.<br>
<br>
<pre class="moz-signature" cols="72">--
--"J"
"I'm a castaway stranded in a desolate land,
I can see the footprints in the virtual sand."
--Neil Peart
</pre>
</body>
</html>