kcat/alure

Alure is a utility library for OpenAL, providing a C++ API and managing common tasks that include file loading, caching, and streaming

alure's Issues

Golang port/interface?

Would it be possible to make a golang port or interface for Alure? It would be incredibly nice since golang has once again interested me and I can't, for the life of me, find any good, high-quality audio libraries that provide 3D, HRTF, and so on, and I don't want to manually interface with a library like FMOD or BASS. (That would just be painful.) Though golang makes interfaing with libraries relatively painless, or as painless as you can make callouts to other libraries not writen in Go, it still would be painful. So are their any plans in the works for such a port or interface?

Alure libraries can't be linked dynamically on Windows

When I tried to build Windows wheel for palace, I has successfully installed OpenAL and alure libraries. However, when the wheel is being built, it is as if these libraries are not there.

Building Custom Rule C:/projects/alure/CMakeLists.txt
  -- Install configuration: "Release"
  -- Installing: C:/Program Files (x86)/alure/lib/alure2.lib
  -- Installing: C:/Program Files (x86)/alure/bin/alure2.dll
  -- Installing: C:/Program Files (x86)/alure/lib/alure2_s.lib
  -- Installing: C:/Program Files (x86)/alure/lib/cmake/Alure2/Alure2Config.cmake
  -- Installing: C:/Program Files (x86)/alure/lib/cmake/Alure2/Alure2Config-release.cmake
  -- Installing: C:/Program Files (x86)/alure/include/AL/alure2.h
  -- Installing: C:/Program Files (x86)/alure/include/AL/alure2-aliases.h
  -- Installing: C:/Program Files (x86)/alure/include/AL/alure2-typeviews.h
  -- Installing: C:/Program Files (x86)/alure/include/AL/alure2-alext.h
  -- Installing: C:/Program Files (x86)/alure/include/AL/efx.h
  -- Installing: C:/Program Files (x86)/alure/include/AL/efx-presets.h
...
  LINK : fatal error LNK1181: cannot open input file 'libalure2-NOTFOUND.obj'
  error: command 'C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\BIN\\x86_amd64\\link.exe' failed with exit status 1181

Please take a look at the full log

Here is the CMakeLists.txt file:

cmake_minimum_required(VERSION 2.6.0)
project(palace)
find_package(Alure2 REQUIRED CONFIG)

get_target_property(include_dirs Alure2::alure2 INTERFACE_INCLUDE_DIRECTORIES)
message("alure2_include_dirs=${include_dirs}")

get_target_property(link_libraries Alure2::alure2 INTERFACE_LINK_LIBRARIES)
get_target_property(libalure2 Alure2::alure2 IMPORTED_LOCATION_NOCONFIG)
message("alure2_extra_objects=${link_libraries};${libalure2}")

Request: Callback for accessing data before sound buffers are initialized

I've recently switched from using OpenAL Soft directly to using alure, and I've run into a small problem:
When loading sound data, I need to be able to convert some stereo sound data to mono before it's being written to a buffer with alBufferData.
Alure doesn't provide any way of accessing the data before the buffer is initialized, so I had to make some modifications to the alure source code to be able to do that.
It would be nice to have some sort of callback or something like that in the future.

Why does Alure have different include files and which files should we use?

Hi,

There are multiple C++ files in the "include" folder in Alure's source. (In https://github.com/kcat/alure/tree/master/inclu)
But when I download it from the site, only include alure.h in the include folder. (Https://kcat.strangesoft.net/alure-releases/alure-1.2-win32-bin.zip)
Msys64-mingw-w64 / mingw-w32 also contains only the alure.h file.
Can you say why this difference is caused?

I want to use Alure to get rid of some of the functions of OpenAL.
However, when I examine the source on GitHub, I see that Alure provides a wrapper for OpenAL. And it is written in C++.
There are different files in the download links on the site and different files in GitHub source.

How can we decide which include folder we should use?

In addition:
There is no win64 dll in the download link.
I was able to install 64bit of the library with msys64.
There is no 64bit DLL in the download link.

And finally:
How can I compile the sample codes in the examples folder?
I could not get out of this problem. I have defined alure32 and openal32 to G++.
Please enter a note about how we can compile samples in the "example" folder for OpenAL-soft and alure?
Such a note would be great in Readme.
I couldn't find any notes on how these examples could be compiled.
G++ shows errors like "__imp___xxxx".

kcat.strangesoft.net site is gone

👋 just to raise the issue in here since the old artifacts are not accessible either.

I am having troubles with include path for OpenAL headers

Currently in Alure, OpenAL's al.h and alc.h are included as if they belong to the include path:

$ ack al\\.h
src/devicemanager.cpp
13:#include "al.h"

include/AL/alure2-alext.h
39:#include "al.h"

include/AL/efx.h
6:#include "al.h"

include/AL/alure2.h
10:#include "al.h"

$ ack alc.h
src/devicemanager.cpp
12:#include "alc.h"

src/context.cpp
16:#include "alc.h"

include/AL/alure2-alext.h
38:#include "alc.h"

include/AL/efx.h
5:#include "alc.h"

According to b5f5f96, this is to shadow broken OpenAL headers on some systems. During compilation of Alure and its examples, there is no error since the headers are in the source directory. However, if one wants to compile the example (or any program using Alure):

$ g++ -lalure alure-enum.cpp
alure-enum.cpp:8:10: fatal error: alure2.h: No such file or directory
    8 | #include "alure2.h"
      |          ^~~~~~~~~~
compilation terminated.

After changing "alure2.h" into <AL/alure2.h>, we get

$ g++ -lalure2 alure-enum.cpp
In file included from alure-enum.cpp:8:
/usr/include/AL/alure2.h:9:10: fatal error: alc.h: No such file or directory
    9 | #include "alc.h"
      |          ^~~~~~~
compilation terminated.

Since I believe OpenAL headers are installed in /usr/include/ for most distros, I added -I/usr/include/AL/ and it compiled alright. However, on NixOS, each package is separated in its own (kind of) fake root, e.g. al.h is at /nix/store/3dvrqgfh9ai8ay6pixjsd9k9qszvxq08-openal-soft-1.19.1/include/AL/al.h. Normally, if it is included as AL/al.h, nix-shell can handle the include path for it alright, but in this case, there might not be any pretty work around.

On the Cython wrapper I'm working on, I have to add /usr/include/AL/ to the include dirs, but I'm quite sure it is not portable, for instance, the host OS may have the header in /usr/local/include/AL/, or it is Windows. Is there any way we can make the compiler to find these OpenAL headers naturally?

Over view of build procedure and dependencies should be in the README.md

Managed to get this all to compile on windows 10 with mingw-w64, it would have helped me a lot to know some steps before attempting to build. Submited request already. Hopefully this will make it easier for people to contribute.

_INCLUDE_DIRS vs _INCLUDE_DIR

Inconsistent naming: . /CMakeLists.txt use MPG123_INCLUDE_DIRS but ./cmake/FindMPG123.cmake use MPG123_INCLUDE_DIR. XXX_INCLUDE_DIRS (with a S) seems to be the convention, so I assume FindMPG123.cmake should be modified. I'm not sure which to use .

My mpg123 is installed (via homebrew) in /usr/local and /usr/local/include is not given to the compiler since ./CMakeLists.txt use the variable with S and this is empty. This gives a compilation error.

Clicks when decoding files (at the end of playback)

Hello, and thank you for doing this amazing library. It is really helpful!

Anyway, I am using it on a Half-Life plugin (https://github.com/LAGonauta/metahook/tree/alure_simple/Plugins/Audio) but when playing the data files from Half-Life there are clicks and pops in the sound at the end. Maybe the decoding is not working as it should?

Most files show this clicking behaviour, some examples are "delayagain.wav" (from the scientists) and "pl_step1.wav". This also happens on the code examples, compiled with MSVC or on MSYS2. On Linux this doesn't seem to happen and every file is decoded as it should.
I can send some samples if you do not have them.

EDIT: Just tested with libsndfile. I disabled the native wav support and compile Alure with libsndfile support using MSVC2017. Works fine now, so there must be a bug hidden in the native wave decoder used by Alure that shows up only on Windows.

Thanks for your time.

fill buffer with data not from file but of a known format

Just as a test I've done this:

struct membuf : std::streambuf
{
    membuf(char* begin, char* end) {
        this->setg(begin, begin, end);
    }
};

class FileFactory final : public alure::FileIOFactory {
private:
    membuf buf;
public:
    FileFactory(membuf &bufin) : buf(bufin)
    {
        std::cout << "hello" << std::endl;
    }

    alure::UniquePtr<std::istream> openFile(const alure::String &name) noexcept override
    {
        auto stream = alure::MakeUnique<std::istream>(&buf);
        if (stream->fail()) {
            std::cout << "failed" << std::endl;
        }
        return std::move(stream); 
    }
};

In my main function I have:
membuf sbuf(existing_buff, existing_buff + sz);
alure::FileIOFactory::set(alure::MakeUnique<FileFactory>(sbuf));

When I run my test I get:
Failed to rewind file for the next decoder factory

This is just a test, I was planning to pass in a map of id,buf in the constructor to the factory if I got this to work.

C++14 only?

Does this only support compilers which support c++14?

Setting the number of channels for a Buffer

If I load a file into a Buffer, is it possible to set the number of channels for this Buffer regardless of the number of channels in the file (or is this a feature which could be implemented?)?

Because according to the OpenAL reference(5.3.4. Specifying Buffer Content), "Buffers containing audio data with more than one channel will be played without 3D spatialization features – these formats are normally used for background music.". If we had this feature, it would be easy to define a sound as a 2D or 3D sound for any file.

DECL_THUNK0->N rename to DECL_IMPL_FORWARDED_FUNCTION[_ARGS[1->N]]

DECL_THUNK is a very ambiguous name, and what the macro is doing is pretty straight forward.

from main.h

#define DECL_THUNK0(ret, C, Name, cv)                                         \
ret C::Name() cv { return pImpl->Name(); }
#define DECL_THUNK1(ret, C, Name, cv, T1)                                     \
ret C::Name(T1 a) cv { return pImpl->Name(std::forward<T1>(a)); }
#define DECL_THUNK2(ret, C, Name, cv, T1, T2)                                 \
ret C::Name(T1 a, T2 b) cv                                                    \
{ return pImpl->Name(std::forward<T1>(a), std::forward<T2>(b)); }
#define DECL_THUNK3(ret, C, Name, cv, T1, T2, T3)                             \
ret C::Name(T1 a, T2 b, T3 c) cv                                              \
{                                                                             \
    return pImpl->Name(std::forward<T1>(a), std::forward<T2>(b),              \
                       std::forward<T3>(c));                                  \
}

We should instead call this DECL_IMPL_FORWARDED_FUNCTION, or optionally ALURE_DECL_IMPL_FORWARDED_FUNCTION in order to avoid namespace conflicts.

the definitions would be changed like so to reflect this, and look like the following for clarity

#define DECL_IMPL_FORWARDED_FUNCTION(ret_type, caller_type, \
func_name, const_qualifier)   \
ret_type caller_type::func_name() const_qualifier { return pImpl->func_name(); }

#define DECL_IMPL_FORWARDED_FUNCTION_ARGS_1(ret_type, caller_type, \
func_name, const_qualifier)   \
arg1); \ 
...
#define DECL_IMPL_FORWARDED_FUNCTION_ARGS_3(ret_type, caller_type, \
func_name, const_qualifier)   \
arg1, arg2, arg3); \

I could submit a pull request for this change if I have the time.

Questions about the project state

1. Is this an official successor to/continuation of https://kcat.strangesoft.net/alure.html. Or "just a fork"
2. Will you be making tagged releases?

Capture and real-time support

Hello,

I am planing on implementing voice communication for a game, but currently Alure does not support capturing voice and playing realtime audio (such as voice received from the internet).

I guess could workaround the second problem by creating a custom decoder that is activated when a specific string is passed to it and the Read method would get the data from a custom voice mixer, but that is far from ideal and the first problem makes this moot anyway.

Is there any plan to add this feature to the library? Thanks.

What is going on with the pimpl implementation ?

I'm quite confused as to why pimpl is implemented as it is, ideally implementation classes of your interface class are declared privately to the interface class, and defined in the same cpp file as the interface class, or defined in separate h/cpp pairs. If we look for the corresponding Buffer for BufferImpl, I see it used, but it gets hard to find where it is actually declared in the repo. Often I see Impls defined with completely different objects which aren't even pimpl, defeating the purpose of using this pattern. Something more along the lines of this is what I was expecting. I do see some impls being used directly, I assume for performance reasons, in internal implementation, but I would expect to see double the number of source files in a typical implementation if one wanted to keep performance access to the implementation, and still doesn't explain most of the patterns I'm seeing.

What is the rational for this?

Why couldn't (or shouldn't) buffers clean themselves?

Hi,

I'm writing a wrapper for alure in Cython for convenience purposes, and I'm wondering which would be the better way to clean up buffers' cache:

1. Let buffers clean themselves. I notice that the API only expose Context::removeBuffer but any other means for buffer to do this. I can just let the context be an attribute of the wrapped buffer, but I want to know if that introduce any risk, i.e. why the C++ API chose not to do it.
2. Let the context track every created buffer. ContextImpl seems to already have mBuffers, is it safe to just call cleanup on all of them upon context destruction? I don't think this is a good idea though since used buffers will hold the cache for no reason.

Have a Merry Christmas or other holiday of your choice.

feature request: direct modification of spatial locations

It would be amazing if there was something akin to source.setPosition that allowed you more direct control of the speaker outputs. i.e. the ability to assign a source to come only out of the center channel or sub channel, or hard panning of left and right.

set3DSpatialize

I use in my program Open AL and in particular the flag AL_DIRECT_CHANNELS_SOFT = true. Moreover, this flag for some reason does not have an effect for the configuration 5.1 of my sound card, but it works great for 7.1 (SB Audigy 5/Rx). Am I correct in understanding that if I need a similar capability when using Alure, then I can use set3DSpatialize ()? Thank you.

Bug in context.cpp

// Edit: Nevermind this, I've created a pull request instead.

There's a small (but with severe consequences) bug in context.cpp in the function ALContext::createSource():

Source *ALContext::createSource()
{
    CheckContext(this);

    ALSource *source;
    if(!mFreeSources.empty())
    {
        source = mFreeSources.back(); // Bug!
        mFreeSources.pop();
    }
    else
    {
        mAllSources.emplace_back(this);
        source = &mAllSources.back();
    }
    auto iter = std::lower_bound(mUsedSources.begin(), mUsedSources.end(), source);
    if(iter == mUsedSources.end() || *iter != source)
        mUsedSources.insert(iter, source);
    return source;
}

mFreeSources is a queue, which means pop removes the first element from it.
However, it retrieves the last element from the queue before popping it. That means source now points to an object still in the queue, and the element which was popped is now dangling.
It should be:

source = mFreeSources.front();

static inline functions that are in source files?

I'm confused as to why there are static inline functions for example in auxeffectslot.cpp or context.cpp. I don't understand what this accomplishes. Is this only used as a guarantee that these functions can only be used within the given source file? If so I'm confused as to why such functions weren't just defined in the source file, I've never seen both static and inline functions in used in a cpp file in C++ before. I don't see the advantage of having "multiple definition" of in this specific circumstance, and "only this translation unit", it appears that you would never have multiple definition, and it would always be defined for that translation unit if you just defined a function?

I also saw this in effect.cpp:

namespace {

template<typename T>
inline T clamp(const T& val, const T& min, const T& max)
{ return std::min<T>(std::max<T>(val, min), max); }

} // namespace

which really made me scratch my head. why is this inlined, why is it in an empty namespace. It looks like you just wanted clamp for this file, even if using C++17 and didn't want to overwrite it any where else? I guess its inlined because you want to have multiple definitions of the same signature? wouldn't it just be better to provide a header to that defines this if you don't have c++17 or just uses c++17 if you have it?

Build errors on macOS Sierra (std::array and constexpr)

The current code does not build on macOS Sierra. It is very easy to fix, however:

• Add #include <array> to the includes in include/AL/alure2.h.
• Remove constexpr from the function Vector3::getLength() in include/AL/alure2.h (std::sqrt() is not a compile time function (constexpr)).

Sample offset should be set only after attaching source to buffer?

I noticed sources that I set the offset were not being played starting at the offset I selected, so I did some investigation.
It seems that Alure sets AL_SAMPLE_OFFSET correctly with OpenAL Soft, but not with Creative's and Rapture3D's drivers.

This function works in those drivers only if AL_SAMPLE_OFFSET is set to a source that has a buffer attached, not before attaching the buffer.
I coded a workaround in Alure just by setting the offset on line 386 (play()) on source.cpp right before playing the source, and shifting mOffset = 0 after the function. The function checkPending() may also need to be modified.

It seems that the specification says nothing about the correct order of operation, is that right? For now I will be using the workaround, but I am sure it can be made prettier. I can do a proper PR if desired.

Thanks.

Clarification on responsibilities of classes in source?

For example, of the following, what are their responsibilities what to they do, what is the intent behind making the class?

• Buffer? Buffer loaded sound data given a decoder and is played from Source?

• Source? - assume source of sound? responsible for playing a stream with 3D sound properties which are configurable?

• SourceGroup? - I assume is a group of sources, which can configure multiple sources as a group?

• Context? - the entire sound environment (actual listener, source group, and special environmental effects)?

• Effect? Pre-made effects which modify the properties of sound in a given context. ?

• Device? Interface to physical media to play/record?

• DeviceManager? Holds multiple devices?

• AuxiliaryEffectSlot? Some how works with effect? not sure how?

"Called context is not current" exception

The newest Alure works: It builds and the examples run well.

I pulled the latest Alure into my project. I had to do some minor modifications in my code to adapt to the newer Alure API, in particular using PIMPL objects in favor of pointers, and now everything compiles.

However, my program gets killed by Alure: Alure throws "Called context is not current" exception(s). They seems to come from void CheckContext(const ContextImpl *ctx)/void CheckContext(const ContextImpl &ctx). I don't know why this happens. Your examples work well. It may have something to do with threads in my program that I am not aware of.

Do @kcat have some suggestions of what causes this error in my program?

Thank you for this great OpenAL library! 🚁

How to safely use Context::precacheBuffersAsync?

As encountered in McSinyx/palace#59, we are struggling to find a way keep the data whose array and string views are passed to Context::precacheBuffersAsync. The primary issue is that it is quite difficult to ensure that the cached version of original strings and their containers and the views reference to the same data.

I have yet to find precacheBuffersAsync used anywhere on GitHHub, but suggest that the method should receive the actual data, e.g. Vector<String> instead, since the size of the argument is usually not significant. If this is possible, this would simplify the usage a lot.

Let CMakeLists.txt export ALURE_LIBRARIES and ALURE_INCLUDE_DIRS

Hello! Is it possible to let ./CMakeLists.txt export ALURE_LIBRARIES and ALURE_INCLUDE_DIRS? I have alure as a git submodule and use it as a cmake submodule (add_subdirectory( alure )). In my top CMakeLists.txt it would be nice to use these variables and not hardcode the paths and link libraries by hand.

For example, the submodule glfw of mine makes this possible:

set(GLFW_LIBRARIES ${glfw_LIBRARIES} CACHE STRING "Dependencies of GLFW")

Is std::out_of_range suitable for out of range floating points?

From cppreference.com, std::out_of_range

reports errors that are consequence of attempt to access elements out of defined range.

Pitch and gain, for example, are floating points values, and thus IMHO should not throw this exception. I'd suggest std::domain_error which is defined as

may be used by the implementation to report domain errors, that is, situations where the inputs are outside of the domain on which an operation is defined.

Here is the list of the current throws of std::out_of_range:

$ ack out_of_range
src/auxeffectslot.cpp
56:        throw std::out_of_range("Gain out of range");

src/buffer.cpp
201:        throw std::out_of_range("Loop points out of range");
286:        throw std::out_of_range("Byte size result too large");

src/source.cpp
396:        throw std::out_of_range("Update length out of range");
398:        throw std::out_of_range("Queue size out of range");
517:        throw std::out_of_range("Fade gain target out of range");
519:        throw std::out_of_range("Fade duration out of range");
811:            throw std::out_of_range("Offset out of range");
977:        throw std::out_of_range("Pitch out of range");
989:        throw std::out_of_range("Gain out of range");
1000:        throw std::out_of_range("Gain range out of range");
1016:        throw std::out_of_range("Distance range out of range");
1181:        throw std::out_of_range("Cone angles out of range");
1196:        throw std::out_of_range("Outer cone gain out of range");
1213:        throw std::out_of_range("Rolloff factor out of range");
1229:        throw std::out_of_range("Doppler factor out of range");
1249:        throw std::out_of_range("Radius out of range");
1282:        throw std::out_of_range("Resampler index out of range");
1294:        throw std::out_of_range("Absorption factor out of range");
1374:        throw std::out_of_range("Gain value out of range");
1386:        throw std::out_of_range("Gain value out of range");
1448:        throw std::out_of_range("Gain value out of range");

src/context.cpp
817:        throw std::out_of_range("Async wake interval out of range");
1610:        throw std::out_of_range("Doppler factor out of range");
1620:        throw std::out_of_range("Speed of sound out of range");
1706:        throw std::out_of_range("Gain out of range");
1777:        throw std::out_of_range("Invalid meters per unit");

src/sourcegroup.cpp
128:        throw std::out_of_range("Gain out of range");
144:        throw std::out_of_range("Pitch out of range");

include/AL/alure2-typeviews.h
80:            throw std::out_of_range("alure::ArrayView::at: element out of range");
99:            throw std::out_of_range("alure::ArrayView::slice: pos out of range");
186:            throw std::out_of_range("alure::BasicStringView::substr: pos out of range");

I believe other than the ones thrown by type views, all should be substituted by a more proper exception.

Disclaimer: the reason I'm filing this issue is that Cython translate std::out_of_range as IndexError while std::domain_error is mapped to ValueError, which is more appropriate in Python context. I am not aware of the current usage of Alure 2 but I assume that backward compatibility might not be a major problem since you haven't made any official release of the new C++11 API.

How to fill buffers with data not from files

I'm curious -- how would I go about generating sine waves without resorting to the OpenAL API? I'd like to generate sine waves (or audio synthesis via oscillators in general) with Alure/OpenAL but have no idea how to do that. I could use a custom decoder, but I have no idea how I'd specify the frequency of the wave, the length, etc., and allow it to be flexible, so I could create a wave with a given length and frequency whenever I needed. Is such a thing possible?

Why did the implementation of alure::AttributePair changed from std::pair to struct?

I am trying to wrap alure in Cython and the implementation of alure::AttributePair caused a bit of inconvenience so I decided to investigate further. To my surprise, it used to be implemented as std::pair instead of a custom struct, but 82436dd changed it to the current one. Another thing I cannot wrap my mind around is that why the attributes has to be null-termination (i.e. {0, 0}).

Would it be more logical to revert back to the previous implementation, or preferably, use std::unordered_map? It would not be a problem for me if it stays as is, but I'm desperate for an explanation for 82436dd.

Forward declaration of alure::ALSource

On macOS Sierra, compilation fails for ./src/device.cpp because alure::ALSource is forward declared in ./src/context.h. The mAllSources member of ALContext (line 78) requires the full datatype (more exactly the std::deque template needs the datatype). If I add #include "source.h" at top of file, everything compiles fine.

PS. For some odd reason it compiles on my Linux computer without any modification.

Can not find `alext.h` on macOS Sierra

I have macOS Sierra, newest XCode, and cmake 3.6.2. It fails during build since it can not find the file alext.h included by ./src/device.h. I can see that there is a file ./include/alext.h. But make -n shows that only the folder ./include/AL is included (not ./include where _alext.h is).

build.txt

lack of RAII in examples despite functionality being present?

Many of the examples include statements like ctx.destroy() or dev.close() while new is no where to be found, and destruction is being called at the end of scope. Is there a particular reason for this pattern? It appears as if all the objects actually have destructors any way.

Please add 3D sound example

The HRTF example currently only create the context with support for HRTF, but does not show how to use 3D sound features. Seemingly after setting 3D spatialize to On, setting position and orientation seems to have some effect, but I can't feel the audio coming from that direction (position is set to be negative of at orientation). Could you please give an example on how to use this feature?

I am so sorry to bother you about this during holiday seasons.

Invalid Source ID (getSampleOffsetLatency)

I've been hunting a peculiar bug all evening that causes periodic segmentation faults when multiple sources are playing. The exit message is always "AL lib: (WW) Error generated on context 0x555555617890, code 0xa001, "Invalid source ID 0""

I loaded up my program in gdb, and it appears to be an issue with Alure, not al-soft. Apologies for any formatting weirdness, the program I'm writing uses ncurses so the formatting in gdb is all over the place. I tried my best to clean it up.

Thread 14 "ncue" received signal SIGSEGV, Segmentation fault.
Switching to Thread 0x7fffe4a46700 (LWP 1136)
0x00007ffff7e4c61e in alure::SourceImpl::getSampleOffsetLatency() const () from /usr/local/lib/libalure2.so
Single stepping until exit from function _ZNK5alure10SourceImpl22getSampleOffsetLatencyEv,
which has no line number information.

On another crash, I got the following:

Thread 11 "ncue" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffcaffd700 (LWP 23024)]
__memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:500
500 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory.

main.h is a very misleading name, and alure::Bitfield shouldn't be located in there

Looking for what the heck DECL_THUNK0->3 are, found it was defined in main.h for some reason. For some reason main.h also has alure::Bitfield, definition inside of it. not sure why this is here, but I can make a pull request if I've got the time to fix this, its really confusing looking at the source code and trying to remember "oh bitfields is in ... main.h?"