joal extension support

Morning,

I'm looking at adding some extension support for joal, specifically for the still unfinished openal-soft loopback device.

Apart from not believing anyone can put up with ant, I think I have the basic stuff going.  I have successfully captured the mixer output into a raw audio dump with a bit of code using the experimental loopback stuff.

I wasn't sure where to put things or how to structure the gluegen code: i just copied the ALC stuff.

Also, I just want o make sure i'm using the right fork from the cms, i presume it's Sven's? https://github.com/sgothel

I've attached the work-in-progress diff , but it's still got a bit of cruft left in it.

I added a bunch of stuff from the current head of openal-soft to alext.h, and the loopback device stuff, which also meant copying all the AL* and ALC* types, and renaming some of the function pointers so gluegen can find the right prototypes.  Messy, but seemed the easiest solution for such a small api.

Cheers,
 !Z

build.diff

Hi

Some support of openal-soft would be really useful as a fallback solution when the hardware accelerated OpenAL implementation is not available. I'm going to look at your source code but it would be better if Sven could read it too.

Edit.: in which case can alExtProcAddressTable be null?

On 02/07/2012 09:26 AM, notzed [via jogamp] wrote: Great stuff - thank you for your work!

>
> I wasn't sure where to put things or how to structure the gluegen code: i
> just copied the ALC stuff.
>
> Also, I just want o make sure i'm using the right fork from the cms, i
> presume it's Sven's? https://github.com/sgothel

Sure, or use jogamp's repo (same state).

>
> I've attached the work-in-progress diff , but it's still got a bit of cruft
> left in it.

Can't you 'just' fork JOAL from the repository (my gluegen/joal or jogamp's
gluegen/joal), make a 'wip' branch (work in progress) we can review ?

>
> I added a bunch of stuff from the current head of openal-soft to alext.h,
yes, and duplicate type defines, which would require manual type validation.

Could you drop the common types in a common file, or just include al.h
in alext.h, while dropping it's generation for those types and functions ?

> and the loopback device stuff, which also meant copying all the AL* and ALC*
> types, and renaming some of the function pointers so gluegen can find the
> right prototypes.  Messy, but seemed the easiest solution for such a small
> api.

After it's cleaned up and hence no side effects occur,
I will pull from your repository - sure.

I know we don't have a lot unit tests in JOAL since it is not so well
maintained. However, since I assume you did test the new functionality
somehow, can you add a few unit tests for it ?

When I write source code, I usually don't add the 'author' tag in the
source files and may just drop our generic JogAmp copyright header.
I know .. others chose to add their 'name'. However, since we all will
edit the files at some point in time, I guess 'personalizing' the files
is a bad idea, since such statement will be always wrong in the future
when many will edit it. Hence not having 'names' in the copyright or
author section won't lead to a long list of names :)
Proper identification of authorship is done via the SCM (IMHO).
>
> Cheers,
>  !Z
>
> http://forum.jogamp.org/file/n3721871/build.diff build.diff

Cheers, Sven

Sven Gothel wrote

>
> I've attached the work-in-progress diff , but it's still got a bit of cruft
> left in it.

Can't you 'just' fork JOAL from the repository (my gluegen/joal or jogamp's
gluegen/joal), make a 'wip' branch (work in progress) we can review ?

No, I don't think so.  I find using git about as offensive as it's name, and you're pretty lucky I somehow managed to get a clean diff out of it.  Every time I try something more complex I end up with a broken repository and the loss of a few hours of life i'll never get back!

>
> I added a bunch of stuff from the current head of openal-soft to alext.h,
yes, and duplicate type defines, which would require manual type validation.

Could you drop the common types in a common file, or just include al.h
in alext.h, while dropping it's generation for those types and functions ?

Sure.  I don't think i can come with a neat regex for the constants though so it might have to be a common file.

> and the loopback device stuff, which also meant copying all the AL* and ALC*
> types, and renaming some of the function pointers so gluegen can find the
> right prototypes.  Messy, but seemed the easiest solution for such a small
> api.

After it's cleaned up and hence no side effects occur,
I will pull from your repository - sure.

I know we don't have a lot unit tests in JOAL since it is not so well
maintained. However, since I assume you did test the new functionality
somehow, can you add a few unit tests for it ?

I added it to a music player, but i suppose i can think something simpler up.

When I write source code, I usually don't add the 'author' tag in the
source files and may just drop our generic JogAmp copyright header.
I know .. others chose to add their 'name'. However, since we all will
edit the files at some point in time, I guess 'personalizing' the files
is a bad idea, since such statement will be always wrong in the future
when many will edit it. Hence not having 'names' in the copyright or
author section won't lead to a long list of names :)
Proper identification of authorship is done via the SCM (IMHO).

Well I just copied some existing file and didn't think it made sense to leave the other name in.  I too find the @author thing a bit pointless but when using netbeans it's too much hassle to turn it off so I ignore it like I do adverts on web pages.

On 02/09/2012 02:24 PM, notzed [via jogamp] wrote: Sorry to hear that you don't like it.
My move to git was because of my frustration with svn,
I really messed up with the server side repository using different
client/server svn versions. Sure, hg would have been an alternative
as well - but you have to choose at some point in time.

Well, ok .. so it is and sure I accept your choice,
even though it makes life harder for us - ie. you cannot directly maintain it.

So we continue on a patch base, I would just need the git hash for which
those patches apply to. Since JOAL is rarely updated .. I guess even that
doesn't matter :)
A common header file is just fine, thank you.
Unit tests ?

Looking forward to merging your [cleaned up] patch manually.

~Sven

Sven Gothel wrote

On 02/09/2012 02:24 PM, notzed [via jogamp] wrote:
> No, I don't think so.  I find using git about as offensive as it's name, and
> you're pretty lucky I somehow managed to get a clean diff out of it.  Every
> time I try something more complex I end up with a broken repository and the
> loss of a few hours of life i'll never get back!
>

Sorry to hear that you don't like it.
My move to git was because of my frustration with svn,
I really messed up with the server side repository using different
client/server svn versions. Sure, hg would have been an alternative
as well - but you have to choose at some point in time.

Well, ok .. so it is and sure I accept your choice,
even though it makes life harder for us - ie. you cannot directly maintain it.

So we continue on a patch base, I would just need the git hash for which
those patches apply to. Since JOAL is rarely updated .. I guess even that
doesn't matter :)

Yeah, well it dates me, but I was an expert on CVS in it's day so I'd prefer that to svn.  It's got it's quirks of course ... but at least it knows how to merge (at the file level), and although the tag implementation is utterly dreadful, the way it is intended to work is better than svn too.  svn struggles at merging and even svn puts hg to shame in that regard (the hg maintainers don't seem to think merging is that important, at least that's the impression i get from the annotated manual and from trying to use it - thankfully 'diff' and 'patch' saved that day - before I decided to throw it out and never use it again).

I've never been working as the configuration manager of a project with hundreds of developers: so git to me is worthless.

> Sure.  I don't think i can come with a neat regex for the constants though
> so it might have to be a common file.

A common header file is just fine, thank you.

Ok.  Should I just drop the version of alext.h from openal-soft in, just leave the merge in as I have so far?  I will also first check with the openal devs as to whether that loopback device extension is likely to remain for the next release.

I put the top sections of al.h and alc.h into al-types.h and alc-types.h respectively.

Unit tests ?

I tried adding one, but I can't ant or whatever to use the openal-soft installed in /usr/local so i can only verify that the open function fails.

On 02/12/2012 10:16 AM, notzed [via jogamp] wrote:
>
>
> I've never been working as the configuration manager of a project with
> hundreds of developers: so git to me is worthless.

The really sad point here is not that I will play the role of your
code merging bitch :) - but that this forbids you to become the JOAL
maintainer. The latter would be great.

Note: I started w/ RCCS/SCCS in around 1994 :)
Awesome.

Yes it would be great if you can make the 'negotiation' w/ the openal devs.
Thank you.

>
>
>> Unit tests ?
>>
> I tried adding one, but I can't ant or whatever to use the openal-soft
> installed in /usr/local so i can only verify that the open function fails.

LD_LIBRARY_PATH=/usr/local/...:$LD_LIBRARY_PATH <java unit test command>

should work, doesn't it ?

the latter maybe ant or a java call (having a main entry in the unit test).

~Sven

Sorry Sven I haven't followed up on this yet - I started back at work 3 weeks ago and just haven't been in the right 'mood' to tackle it when i've had spare time.

One patch and you think I should start maintaining my own fork?  Hah!  Patch bitch?  Hardly!  I'm only doing this for fun.

I can't remember why i couldn't get the unit tests to run properly now, but i'm sure LD_LIBRARY_PATH is the first thing I would've tried - as it's how i usually customise my work environment.  ant just gives me the mega-shits because it's such a stupid piece of software, and it is a big reason I haven't spent any more time on this.  I've never used junit either, so all i had to go on was what was there already.

I did get in touch with the openal devs, and they think the api will remain and a release isn't too far off.

I think I had the patch mostly done before I had a think-o replacing a dead drive and had to re-install and recover everything - which was the final nail in the coffin for any enthusiasm i had left (for something i probably wont be looking at again for the foreseeable future).  All the stuff I did is restored, but I wanted to use the opportunity to clear out a bit of cruft and so some of the rest is not there.

So the patch isn't dead, it's just resting.

On 03/09/2012 03:32 AM, notzed [via jogamp] wrote:
>
>
> Sorry Sven I haven't followed up on this yet - I started back at work 3 weeks
> ago and just haven't been in the right 'mood' to tackle it when i've had
> spare time.

Hi 'Notzed', great to hear from you again.

>
> One patch and you think I should start maintaining my own fork?  Hah!  Patch
> bitch?  Hardly!  I'm only doing this for fun.

I love it when the humor is being picked up :)
I meant 'I will be your patch bitch' :)

Well, it can't be Christmas every day 'eh ?
but would have been nice if somebody skilled picks up the
maintenance. But I guess JOAL is sort of 'complete'.

>
> I can't remember why i couldn't get the unit tests to run properly now, but
> i'm sure LD_LIBRARY_PATH is the first thing I would've tried - as it's how i
> usually customise my work environment.  ant just gives me the mega-shits
> because it's such a stupid piece of software, and it is a big reason I
> haven't spent any more time on this.  I've never used junit either, so all i
> had to go on was what was there already.

LD_LIB.. shouldn't be required anymore. Maybe you have missed the new
native library loading ?

Yeah, 'ant' is limited indeed - but it does what we tell it to do,
even though we had a hard time w/ cpptasks :)

Personally I still prefer makefiles.

>
> I did get in touch with the openal devs, and they think the api will remain
> and a release isn't too far off.

great news.

>
> I think I had the patch mostly done before I had a think-o replacing a dead
> drive and had to re-install and recover everything - which was the final
> nail in the coffin for any enthusiasm i had left (for something i probably
> wont be looking at again for the foreseeable future).  

I know that feeling. Since such a thing happened to me a few times,
I only run things on raid1 plus having rsync backups etc.

And while having raid1 w/ 2 disks, very often one just got killed.
Can't imagine the anger w/o the redundancy.

> All the stuff I did
> is restored, but I wanted to use the opportunity to clear out a bit of cruft
> and so some of the rest is not there.
>
> So the patch isn't dead, it's just resting.

Really good to hear, thank you.

So I am here to look at your patches and merge them, no problem.

Cheers, Sven

Thank you Michael your patch is now merged in JOAL.
https://jogamp.org/bugzilla/show_bug.cgi?id=567