[openal] Alure problem with vs2013

developer at oldunreal.com developer at oldunreal.com
Tue May 26 04:31:23 EDT 2015

On 25.05.2015 18:37, Chris Robinson wrote:
> On 05/25/2015 06:27 AM, developer at oldunreal.com wrote:
>> Yet another report about this issue.
>> I made an entirely new build based on VS2008 now, to verify my
>> experiences with VS2013. Unfortunately I can't use the dynload option
>> for VS2008 since its not having decltype and is failing with missing
>> typeof definition then (no clue how to get around this right now).
> There's probably some template trickery you could do, but I don't much 
> see the point since dynload is a bad idea anyway. It just causes some 
> codecs to silently not work at run-time if the library doesn't load 
> for some reason.
Actually for MP3 support I found dynload kinda interesting since it 
allowed me to enhance ALURE in places where needed simply by adding the 
mpg123.dll and avoided it if not needed due to the common license 
problems with that format, but as said, I fully agree with you here, it 
is a bad idea due to the trouble it can cause- currently its only in use 
by me because I haven't found another way.
>> Either way, in both cases mpg123 does not work without DYNLOAD option.
> That's rather interesting. mpg123 is the one codec that gave me quite 
> a bit of trouble to work with dynload, since I couldn't use a number 
> of its normal functions. What problems do you have without dynload?
The old story, no matter what I try, it always gives me "Unsupported 
type" (to avoid external problems I also used alureplay for testing).
>> On 17.05.2015 01:05, Chris Robinson wrote:
>>> As of right now, it supports libmpg123 and libsndfile (which supports
>>> vorbis, flac, and some other formats). It also allows you to specify
>>> your own decoders if you want to use something else.
> FWIW, it now also uses libvorbisfile and libFLAC directly, without the 
> need for libsndfile. It also has its own wave file handler for formats 
> that OpenAL can take directly, and which will read smpl chunks for 
> loop points to automatically set them on buffers using 
> AL_SOFT_loop_points. I haven't yet looked into how vorbis and flac 
> files specify loop points, if they do at all, so only wave files have 
> automatic support for loop points... though they can still be 
> specified manually if the extension is supported.
Indeed, I didn't think about looppoints here yet, interesting to find 
out. From what I remember there is no such thing in ogg, but no idea 
about flac.

More information about the openal mailing list