[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On 12 April 2010 15:15, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> Okay, here it goes. Create an acodec addon that:
>
> * has al_load_sample, al_load_sample_f, al_load_sample_type, etc...
> * has no explicit load/save functions (e.g., no al_load_wav)
> * has native support for wav
> * has (optional) dynamic support for ogg, flac, mod
> * no need to init the acodec addon, but you must link against it***
Hmm...
> * remove the need for allegro_flac, allegro_ogg, allegro_modaudio
>
> If you choose to build the acodec add-on (default option), every
> supported file format will *always* be registered (ogg, flac, it, mod,
> xm, s3m, wav). If you don't have the third party libraries at Allegro
> compile time, then they will be loaded dynamically on demand at run
> time. Obviously if the DLL is not found at that point, the NULL sample
> is returned.
>
> Thus, there is no way to disable support for any singular audio codec.
> If you have, e.g. dumb.dll or flac.dll, it will always work with
> allegro_acodec.dll.
>
> If possible it would be nice to not even require that the header files
> be present. I was able to accomplish that with libdumb with minimal
> effort.
>
> *** Acodec could be part of audio. Obviously it depends on it.
> However, there is a clear cut line between acodec's and audio's
> functionality. Personally, I think they should remain separate.
I think al_init_acodec_addon() should be required to maintain the separation.
> * "foo" autodetect full name => "libfoo.so" (UNIX) or "foo.dll" or
> "libfoo.dll" (Windows)
> * "foo.dll" only try foo.dll, since the extension is present.
>
Firstly, on Linux that's going to be a problem due to distribution
quirks. On one distro, foo might be named libfoo.so, another might
have it as libfoo-1.so. libfoo.so might be ABI-incompatible with the
version that acodec was compiled with, e.g. different structure sizes.
On Windows, I don't know if the problem is acute but I've seen
different copies of FLAC around, under the names so similar problems
might apply.
DUMB's build system doesn't even build a shared library as far as I remember.
I think the more robust solution is for acodec to load our own DLLs
(like allegro_acodec-FLAC.dll) which link to FLAC. The number of DLLs
will not increase if you statically link the dependencies into the
Allegro modules.
Peter