Bug 567

Summary: add support for openal extensions
Product: [JogAmp] Joal Reporter: notzed
Component: coreAssignee: Sven Gothel <sgothel>
Status: RESOLVED FIXED    
Severity: enhancement CC: xerxes
Priority: ---    
Version: 1.0   
Hardware: All   
OS: all   
Type: --- SCM Refs:
3cf2b66e13104b372611b3a9dbb722110370a9c7 4885e2a488223b852598520664875804d302d3e3 490096c7c53030170876f568ec1f0953a66fbb1d
Workaround: ---
Bug Depends on:    
Bug Blocks: 662    
Attachments: the patch being held
version with correct extension name in test

Description notzed 2012-03-17 23:39:40 CET
Created attachment 343 [details]
the patch being held

here's the patch.

I updated the al*h files to the latest ones from openal-soft (pre-release of openal-1.14).  Mostly minor changes, although without this the al-efx.h file wouldn't load.

I still can't get the test to run - well it runs but it only runs against the system openal library (despite using ld-library-path), so it doesn't find the extension.  I think the extension name might have changed compared to a small test programme I wrote separately which I know worked, so I changed that to what I think the new one is.

I had to fix some joal code which doesn't run against the current gluegen (Debug.java).

afaict it's against sven's git revision:
bb177035f42c650f1f66ed172efc65c34b180c31
Comment 1 notzed 2012-03-17 23:42:29 CET
Created attachment 344 [details]
version with correct extension name in test

sorry, previous one didn't have the changed extension name in the test.

it of course, still doesn't find the extension.
Comment 2 Sven Gothel 2012-04-17 16:47:22 CEST
I am reading your patch now - sorry a bit late.
Looks great, even a unit test. thank you!

If you can clarify #1 I can merge the code.
#2 would be nice to know.

+++

#1

You removed the (c) of the header files, how can you do this ?
Do you use a non (c) source for your changes ?
What is the source of your headers ?

+++
#2

ALproc -> (void *) 
  Isn't it more declarative to have ALproc or did the 'official' header changes ?

+++
Comment 3 Xerxes Rånby 2013-01-25 13:30:47 CET
(In reply to comment #2)
> I am reading your patch now - sorry a bit late.
> Looks great, even a unit test. thank you!
> 
> If you can clarify #1 I can merge the code.
> #2 would be nice to know.
> 
> +++
> 
> #1
> 
> You removed the (c) of the header files, how can you do this ?
> Do you use a non (c) source for your changes ?
> What is the source of your headers ?
> 
> +++
> #2
> 
> ALproc -> (void *) 
>   Isn't it more declarative to have ALproc or did the 'official' header changes
> ?
> 
> +++

A: #1 & #2
It looks to me that notzed have based the headers from OpenAL-Soft
The headers of OpenAL-soft do not contain a copyright in the headers of the inludes:

Original OpenAL headers are: /joal/make/stub_includes/openal/
al.c  alc.h  alext.h  al.h  alut.h  eax.h  efx.h

OpenAL-Soft headers are: /openal-soft/include/AL/
alc.h           alext.h         al.h            efx-creative.h  efx.h           efx-presets.h

Note that some headers found in the original OpenAL headers are missing in OpenAL-soft compared to the original OpenAL headers expecially:
* EAX eax.h (support for the creative only hardware specific extensions) possibly replaced by efx-creative.h in OpenAL-soft
* al.c

There is two new files added by notzed patch that have no explanation and no header:
alc-types.h
al-types.h


So to resolve this situation i suggest the following:
Fist we should switch the headers used by JOAL to the unmodified headers from OpenAL-soft with included EFX support. Then we merge the changes that only alters JOAL files only from notzed patch. And finally fix any incompatibility by using the new OpenAL-soft headers.
Comment 4 Xerxes Rånby 2013-01-25 15:00:09 CET
A: #1 & #2
This post verify the assumption that notzed used and added some modifications to the OpenAL-soft headers
http://forum.jogamp.org/openal-extensions-patch-td3835494.html
"Oh, and I forgot to mention in the bug: don't ask me what is up with the copyright jumping around in the openal-soft headers, I just thought it best to change them as little as possible and that's how they came this time."
Comment 5 Xerxes Rånby 2013-01-25 15:55:27 CET
(In reply to comment #3)
> (In reply to comment #2)
> There is two new files added by notzed patch that have no explanation and no
> header:
> alc-types.h
> al-types.h

These two headers looks like they are a replacement for including the system
/usr/include/linux/stddef.h
and possibly
/usr/include/inttypes.h

I will try alter the JOAL gluegen to use the system headers
Comment 6 Xerxes Rånby 2013-01-25 16:37:32 CET
(In reply to comment #3)
> So to resolve this situation i suggest the following:
> Fist we should switch the headers used by JOAL to the unmodified headers from
> OpenAL-soft with included EFX support. Then we merge the changes that only
> alters JOAL files only from notzed patch. And finally fix any incompatibility
> by using the new OpenAL-soft headers.

I have started a, work in progress, EFX branch to implement the merge outlined in the suggestion above:
https://github.com/xranby/joal/tree/EFX
Comment 7 Xerxes Rånby 2013-01-31 11:41:22 CET
The patch have been merged.
https://github.com/sgothel/joal/pull/8

JOAL is now able to run the testAlCLoopbackDeviceSOFT(com.jogamp.openal.test.junit.ALExtLoopbackDeviceSOFTTest)
junit test an is able to find and use the OpenAL-soft loopback extension.

The written buffer generated by using the loopback extension is not bit identical to the original buffer. This is kind of expected, we need to polish the junit test a little more. But all in all OpenAL extensions work after the merge!

(11:30:41) sgothel: There was 1 failure:
(11:30:41) sgothel: 1) testAlCLoopbackDeviceSOFT(com.jogamp.openal.test.junit.ALExtLoopbackDeviceSOFTTest)
(11:30:42) sgothel: java.lang.AssertionError: expected:<127> but was:<-128>
(11:30:44) sgothel:         at com.jogamp.openal.test.junit.ALExtLoopbackDeviceSOFTTest.testAlCLoopbackDeviceSOFT(ALExtLoopbackDeviceSOFTTest.java:102)
Comment 8 Sven Gothel 2013-02-01 11:57:53 CET
We bundle OpenAL-Soft and build for Linux, Android and OSX.

Note: 
- Windows is still in progress.
- On OSX we prefer the system OpenAL, since OpenAL-Soft provides no output devices here.