OpenAL Soft 1.6.372 released!

[Chris Robinson-5]

Finally got out another release. Hopefully it's a good one. :)

http://kcat.strangesoft.net/openal.html

This release includes fixes for pops and clicks caused by fast position
changes and when starting playback in the middle of a buffer, adds a
Solaris-native backend (playback only), non-mmap ALSA capture and better ALSA
capture support in general, a new low-pass filter to better match I3DL2 spec
behavior, and a completely new reverb engine, coded from scratch by
Christopher Fitzgerald (who has my undying thanks for not only replacing the
poor excuse for reverb I initially put in, but also for making one that
sounds awesome.. and for helping with the new low-pass filter).

There's also a new preliminary CMake option, XCOMPILEWIN32, to build a Win32
DLL from Linux/Unix:
export CC=mingw32-gcc
cmake .. -DXCOMPILEWIN32=ON
There's still some oddities with it due to CMake not working too well with
cross-compiling, but it creates a usable DLL all the same.

>From here, we're gonna try improving the new reverb code, and hopefully
implement some more options for it. I'm also going to see about what can be
done with the proposed AL_EXT_buffer_sub_data, AL_EXT_attenuation_table, and
AL_EXT_source_distance_model extensions.. and perhaps see about an
AL_EXT_query_timer extension for an app to be able to read and time using the
DSP timer.

As always, comments and questions are welcome. :)
- Chris

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Ludwig Nussel]

Chris Robinson wrote:
> There's also a new preliminary CMake option, XCOMPILEWIN32, to build a Win32
> DLL from Linux/Unix:
> export CC=mingw32-gcc
> cmake .. -DXCOMPILEWIN32=ON
> There's still some oddities with it due to CMake not working too well with
> cross-compiling, but it creates a usable DLL all the same.

Is that special flag actually needed? I was able to cross compile
previous openal-soft versions just fine already AFAICT[1]. I use the
following toolchain file:

# the name of the target operating system
SET(CMAKE_SYSTEM_NAME Windows)

# which compilers to use for C and C++
SET(CMAKE_C_COMPILER /opt/cross/bin/i386-mingw32msvc-gcc)
SET(CMAKE_CXX_COMPILER /opt/cross/bin/i386-mingw32msvc-g++)

# here is the target environment located
SET(CMAKE_FIND_ROOT_PATH /opt/cross/i386-mingw32msvc)

# adjust the default behaviour of the FIND_XXX() commands:
# search headers and libraries in the target environment, search
# programs in the host environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)



cu
Ludwig

[1] http://download.opensuse.org/repositories/home:/lnussel:/win32/win32/
    https://build.opensuse.org/project/show?project=home%3Alnussel%3Awin32

--
 (o_   Ludwig Nussel
 //\   SUSE LINUX Products GmbH, Development
 V_/_  http://www.suse.de/


_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Chris Robinson-5]

On Sunday 23 November 2008 08:29:58 am Ludwig Nussel wrote:
> Is that special flag actually needed? I was able to cross compile
> previous openal-soft versions just fine already AFAICT[1]. I use the
> following toolchain file:

I'm not sure how this is supposed to work. CMake will only look for a
CMakeLists.txt in the directory path its given, so I tried putting it in a
seperate directory to include the previous one, but it expects the source
files to be relative from the new sub-directory and won't find them.

I also tried pasting it to the top of the current CMakeLists.txt (changing the
paths to reflect my system), but it still didn't realize it was building for
Windows (the IF(WIN32) checks fail). Using the XCOMPILEWIN32 option worked
and it could build a DLL, but this doesn't seem much better than what it does
now (though it did get rid of the annoying -fPIC and -rdynamic warnings).

I could probably clean it up a bit more to get it to work better, but is there
something I'm missing? I've never had much luck when cross-compiling with
CMake, and the people I talk to that use CMake don't seem to know how,
either.

- Chris
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Ludwig Nussel]

Chris Robinson wrote:
> On Sunday 23 November 2008 08:29:58 am Ludwig Nussel wrote:
> > Is that special flag actually needed? I was able to cross compile
> > previous openal-soft versions just fine already AFAICT[1]. I use the
> > following toolchain file:
>
> I'm not sure how this is supposed to work. CMake will only look for a
> CMakeLists.txt in the directory path its given, so I tried putting it in a
> seperate directory to include the previous one, but it expects the source
> files to be relative from the new sub-directory and won't find them.

In the .spec file for the openal-soft-win32-1.5.304 package I have
the following call (%SOURCE99 is the toolchain file):

cd CMakeConf
cmake \
    -D CMAKE_TOOLCHAIN_FILE=%SOURCE99 \
    -D CMAKE_INSTALL_PREFIX=/opt/cross/i386-mingw32msvc \
    -D CMAKE_C_FLAGS:STRING="$RPM_OPT_FLAGS" \
    ..

Which results in calls like this:

[ 23%] Building C object CMakeFiles/openal32.dir/OpenAL32/alExtension.obj
/opt/cross/bin/i386-mingw32msvc-gcc  -DAL_BUILD_LIBRARY -Dopenal32_EXPORTS -march=i586 -mtune=i686 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -O2 -g -O2 -funroll-loops -D_DEBUG -I/usr/src/packages/BUILD/openal-soft-1.5.304/OpenAL32/Include -I/usr/src/packages/BUILD/openal-soft-1.5.304/include -I/usr/src/packages/BUILD/openal-soft-1.5.304/CMakeConf   -Wall -Wextra -o CMakeFiles/openal32.dir/OpenAL32/alExtension.obj   -c /usr/src/packages/BUILD/openal-soft-1.5.304/OpenAL32/alExtension.c

cu
Ludwig

--
 (o_   Ludwig Nussel
 //\   SUSE LINUX Products GmbH, Development
 V_/_  http://www.suse.de/





_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Chris Robinson-5]

On Sunday 23 November 2008 11:33:45 am Ludwig Nussel wrote:
> In the .spec file for the openal-soft-win32-1.5.304 package I have
> the following call (%SOURCE99 is the toolchain file):
>
> cd CMakeConf
> cmake \
>     -D CMAKE_TOOLCHAIN_FILE=%SOURCE99 \
>     -D CMAKE_INSTALL_PREFIX=/opt/cross/i386-mingw32msvc \
>     -D CMAKE_C_FLAGS:STRING="$RPM_OPT_FLAGS" \
>     ..

Ah, I see. Seems the CMAKE_TOOLCHAIN_FILE define was added for CMake 2.6, and
won't work for 2.4. I don't think I would have a problem requiring 2.6 for
cross-compiling, though it may cause issues for Gentoo users who only have
2.4 in stable. Non-cross-compile builds will still need to work on 2.4 for
now, though.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel