OpenAL- ALSA advanced features hardware support update.

OpenAL- ALSA advanced features hardware support update.

[Manuel Jander]

Hi,

I updated my ALSA- OpenAL interface proposal, taking into account some
suggestions i have received, and some further investigations, specially
on the side of OpenAL.

Take a look at:
http://galadriel.mat.utfsm.cl/~mjander/aureal/alsa/OpenAL-ALSA.txt

AFAIK, the linux OpenAL port was not designed taken any hardware support
into account. 

Things that go against my goals are:

- OpenAL only uses one single ALSA substream. There is no substream
management (must be added).
- OpenAL is not hardware mixing aware.
- OpenAL ALSA structs must be changed to integrate hardware context
data.

Things that are favorable:

- As far as i dug into OpenAL, it seems that all source buffer
processing is done in one single place (_alMixSources). Replacing this
call for hardware assisted sources seems feasible.


The same as for the first iteration of this proposal, please take some
minutes and give some comments/suggestions back. I need feedback.

Best Regards

-- 
Manuel Jander
mjander(at)users(dot)sourceforge(dot)net



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: OpenAL- ALSA advanced features hardware support update.

[Glenn Maynard]

(Oops.  Sent privately unintentionally; resending to the list.)

On Sun, Dec 21, 2003 at 11:24:00PM -0400, Manuel Jander wrote:
> The same as for the first iteration of this proposal, please take some
> minutes and give some comments/suggestions back. I need feedback.

I'll give some higher level feedback:  Why OpenAL?  

I looked at it about a year ago, while rewriting the sound system for
a game with relatively strict sound demands. (StepMania; we wanted
hardware mixing, when possible, and sound-to-gameplay sync to be as
tight as possible, within a couple ms).

I couldn't find any active mailing lists.  I couldn't even find any
indication that anyone was working on it at all.  I read some of the
Windows source code, and saw what is--without exaggeration--some of
the most heinous, seizure-inducing code I've ever seen.  (There were
conditionals and loops nested something like 12 levels deep.  I don't
think the programmer understood the concept of the "return" keyword.)

And although the API was decent to look at, it had no way of getting an
accurate hardware play cursor, or any other mechanism to get a good idea
of the currently-playing sample (for eg. graphical sync).  We couldn't
reliably sync sound with any smaller resolution than a whole buffer.

I don't think OpenAL has a future.  Do you really want to invest your time
in it?

-- 
Glenn Maynard


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: OpenAL- ALSA advanced features hardware support update.

[Mark Constable]

On Mon, 22 Dec 2003 02:27 pm, Glenn Maynard wrote:
> ...
> I don't think OpenAL has a future.  Do you really want to invest your time
> in it?

From the linked text...

 OpenAL is useful mostly for games and multimedia where you want
 3D positional audio to be rendered in a realistic fashion. Some 
 soundcards provide various speakers to do so, others use special
 filters to simulate the direction where the sound comes from.
 The latter works specially good using headphones. OpenAL is like
 DirectSound3D and EAX but cross platform.

Q: what is an alternative strategy if OpenAL is so "useless" ?

--markc


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id\x1278&alloc_id371&op=click

OpenAL & more

[Jaroslav Kysela]

On Sun, 21 Dec 2003, Manuel Jander wrote:

> Hi,
> 
> I updated my ALSA- OpenAL interface proposal, taking into account some
> suggestions i have received, and some further investigations, specially
> on the side of OpenAL.
> 
> Take a look at:
> http://galadriel.mat.utfsm.cl/~mjander/aureal/alsa/OpenAL-ALSA.txt
> 
> AFAIK, the linux OpenAL port was not designed taken any hardware support
> into account. 
> 
> Things that go against my goals are:
> 
> - OpenAL only uses one single ALSA substream. There is no substream
> management (must be added).
> - OpenAL is not hardware mixing aware.
> - OpenAL ALSA structs must be changed to integrate hardware context
> data.
> 
> Things that are favorable:
> 
> - As far as i dug into OpenAL, it seems that all source buffer
> processing is done in one single place (_alMixSources). Replacing this
> call for hardware assisted sources seems feasible.
> 
> 
> The same as for the first iteration of this proposal, please take some
> minutes and give some comments/suggestions back. I need feedback.

Ok, regarding the last feedback:

1) try to make all controls non OpenAL specific
   - naming should be generic something like - "Ext3D ..."
   - the ranges and usage might be different per hardware
2) alsa-lib should provide a common entry point for all 3D APIs
   - I propose to have a special name for stream like "surround3d";
     note that stream in my eyes is one "voice"; we can use hw mixing
     or dmix in case when hw mixing is not available for final output
   - we need to add runtime controls for PCM streams to alsa-lib (see bottom),
     these controls will eventually map to hw controls or they won't be
     present in case when hardware acceleration does not exist

Proposal for runtime PCM controls:
==================================

int snd_pcm_control_list(snd_pcm_t * handle, snd_config_t ** list);
int snd_pcm_control_set(snd_pcm_t * handle, snd_config_t * value);
int snd_pcm_control_get(snd_pcm_t * handle, snd_config_t * value);

A short description: snd_pcm_control_list() returns a compound with list
of all keys (names of variables - controls - assigned to a PCM stream) and
other useful information (ranges, types, user representation etc.).  
snd_pcm_control_set() and snd_pcm_control_set() functions will set and get
the contents of value identified by given key.

Note that value might be also a compound so very complex data structures
might be passed through.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: OpenAL- ALSA advanced features hardware support update.

[Manuel Jander]

On Sun, 2003-12-21 at 22:38, Glenn Maynard wrote:
> On Sun, Dec 21, 2003 at 11:24:00PM -0400, Manuel Jander wrote:
> > The same as for the first iteration of this proposal, please take some
> > minutes and give some comments/suggestions back. I need feedback.
> 
> I'll give some higher level feedback:  Why OpenAL?  

Do you know about any other alternative ?? I don't.

> I looked at it about a year ago, while rewriting the sound system for
> a game with relatively strict sound demands. (StepMania; we wanted
> hardware mixing, when possible, and sound-to-gameplay sync to be as
> tight as possible, within a couple ms).
> 
> I couldn't find any active mailing lists.  I couldn't even find any
> indication that anyone was working on it at all.  I read some of the
> Windows source code, and saw what is--without exaggeration--some of
> the most heinous, seizure-inducing code I've ever seen.  (There were
> conditionals and loops nested something like 12 levels deep.  I don't
> think the programmer understood the concept of the "return" keyword.)
> 
> And although the API was decent to look at, it had no way of getting an
> accurate hardware play cursor, or any other mechanism to get a good idea
> of the currently-playing sample (for eg. graphical sync).  We couldn't
> reliably sync sound with any smaller resolution than a whole buffer.
> 
> I don't think OpenAL has a future.  Do you really want to invest your time
> in it?

I agree that the implementation isn't the best. But its not about the
particular implementation. Its about standards. If you look at OpenAL,
its mostly a imitation of Aureals A3D. Some name changed, but in essence
just like A3D, most of its look and feel (of the API) has been borrowed
from OpenGL.

For know i don't have the time to write a new library and pretend it to
be adopted widespread by others. If we support OpenAL, the
implementation may be improved, once it is working.

Best Regards.

Manuel Jander




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click