[Bf-committers] C++11 Audaspace
nexyon at gmail.com
Tue Jul 28 14:10:36 CEST 2015
I have just pushed the changes to master. Please report any problems
that might appear to me either here or even faster on IRC!
In overall the changes look like this:
- By default the internal/old audaspace library is used and to use the
new one you need to enable WITH_SYSTEM_AUDASPACE in cmake.
- Scons does not have this flag.
- Blender releases will still be made with the internal/old library for now.
- UI: The system configuration dialog now shows a drop down list instead
of the buttons for the device.
- The internal/old audaspace API naming has been changed to correspond
to the new API.
- Devices are now handled with strings instead of ID numbers also for
compatibility with the new API and future support of new devices.
- The Game Engine uses the C API instead of the C++ code in order to not
require C++11 support to compile blender with the new audaspace library
and simplify the code to be used with both versions of the library.
To try the new audaspace library:
- Linux: you need to build and install the new audaspace library 
yourself. For arch linux there is already a PKGBUILD in AUR . If you
don't want to install it you can either set the paths for includes and
libraries manually with ccmake or set the environment variable
AUDASPACE_ROOT_DIRto help cmake finding it itself. If any linux
distribution developers read this, please feel free to contact me
regarding an official release of the library and a package for your
distribution to be prepared for when blender switches to the new library
for official releases.
- Windows: I have already built audaspace on windows and used it to
compile with blender so this should work. However there is no library in
the svn libs folder yet. It would be great if the windows platform
maintainers (Thomas, Martijn) could do so. I will of course assist with
building audaspace for anyone who wants to build it themselves.
- Mac: As I don't have a Mac I couldn't try this. There might be some
small problems to get audaspace with blender to work, but I don't too
many. Apart from that the same statements (no library in svn libs,
platform maintainers (Jens, Martijn), offer to help building) as for
On 2015-05-04, 14:42 Jörg Müller wrote:
> I've talked to Campbell about this on IRC as well, he suggests that we
> do both, have the library in extern and allow a system installed with
> a corresponding cmake option.
> I've tried to build audaspace C++11 with older versions of gcc, it
> works fine with gcc 4.7.4 and it needs minor changes to work with gcc
> 4.6.2, so I think we would be fine to use it.
> The benefit is at the moment a better Python API and a more stable
> library. In the long run there will be more benefits as new features
> will be added only to the new audaspace. One of the planned features
> is to implement native audio backends for each platform, so that we
> have direct support of Core Audio (Windows, Mac, different libraries
> but same name...), ALSA and pulseaudio. This should also result in
> closing some bugs in the tracker that are caused by OpenAL soft for
> So my plan is to integrate the new library with blender and merge this
> to master after the 2.78 release if we approve it in bcon1. The point
> is to have it in master and test it on all platforms. Keeping the old
> version allows to use that for release still, we can delete it as soon
> as we decide to release with the new version.
> Any further comments on this?
> On 2015-04-15, 17:09 Sergey Sharybin wrote:
>> I'm not sure why you cncluded it's mainly Linux issue. You'll need to
>> upgrade OIIO/OSL on all platforms i.e. You might avoid doing that if
>> audaspace is only communicated via C-API (which i'm not sure about).
>> if requirenment is indeed gcc-4.8, then we can't limit C++11 to
>> sine it'll fail to compile anyway.
>> On Windows msvc2013 silently provides you some subset of of C++11. On
>> official builds are done with clang-3.5 with openmp patch, i'm not sure
>> what regular users are using there for compilation. For a long time
>> it was
>> gcc on buildbot machine.
>> About using old audspace for linux -- all the releases must use same
>> library versions. You can't updade one library for one platform and keep
>> old library for another.
>> Again, actual question which is about whether we really want to cause
>> a build environment requiruirenment bump. And in order to make decisions
>> about that it is important to know what users will gain from this
>> (which is
>> still unclear). We don't break anything just because it makes code
More information about the Bf-committers