mirror of
https://github.com/ZDoom/gzdoom-gles.git
synced 2024-12-20 17:31:10 +00:00
01f59fa85f
heavily customized version of DUMB (Dynamic Universal Music Bibliotheque).
It has been slightly modified by me:
* Added support for Ogg Vorbis-compressed samples in XM files ala FMOD.
* Removed excessive mallocs from the replay core.
* Rerolled the loops in resample.c. Unrolling them made the object file
~250k large while providing little benefit. Even at ~100k, I think it's
still larger than it ought to be, but I'll live with it for now.
Other than that, it's essentially the same thing you'd hear in foobar2000,
minus some subsong detection features. Release builds of the library look
like they might even be slightly faster than FMOD, which is a plus.
- Fixed: Timidity::font_add() did not release the file reader it created.
- Fixed: The SF2 loader did not free the sample headers in its destructor.
SVN r995 (trunk)
141 lines
6.4 KiB
Text
141 lines
6.4 KiB
Text
al_duh_get_volume()
|
|
|
|
* [23:25:12] <Mahogny> I prefer an API datagram :)
|
|
|
|
* Create a glossary of terms like 'render', 'sigrenderer', etc.?
|
|
|
|
* Consider the order in which stuff appears in dumb.h, and dumb.txt?
|
|
|
|
|
|
PROPOSED CHANGE OF TERMINOLOGY:
|
|
|
|
Current situation:
|
|
|
|
A DUH comprises a number of "signals". A signal is an entity capable of
|
|
producing a stream of audio. When a signal is called upon to generate
|
|
sound, it may in turn call upon any other signals in the DUH and use the
|
|
sound from those in generating its own.
|
|
|
|
There are a number of "sigtypes", including 'SAMP' (a sample) and 'SEQU'
|
|
(a sequence). Every signal in a DUH must be of one of these known types.
|
|
Every sigtype is characterised by a four-byte identifier and the
|
|
following function prototypes:
|
|
|
|
typedef void signal_t;
|
|
typedef void sampinfo_t;
|
|
|
|
signal_t *load_signal(DUH *duh, DUMBFILE *file);
|
|
sampinfo_t *start_samples(DUH *duh, signal_t *signal, int n_channels, long pos);
|
|
void set_parameter(sampinfo_t *sampinfo, unsigned char id, long value);
|
|
long render_samples(sampinfo_t *sampinfo, float volume, float delta, long size, sample_t **samples);
|
|
void end_samples(sampinfo_t *sampinfo);
|
|
void unload_signal(signal_t *signal);
|
|
|
|
When a signal in a DUH needs to be loaded, DUMB's core first checks the
|
|
identifier. If it is unknown, load_duh() fails. Each known sigtype will
|
|
have pointers to the above functions, so DUMB's core will then call the
|
|
load_signal() function. This loads the "signal", which could consist of
|
|
sample data, or sequence data (like the patterns in a music module).
|
|
(There's ambiguity here; we use the word "signal" for the whole entity
|
|
and also for the specific data that distinguish it from other signals of
|
|
the same sigtype.)
|
|
|
|
Once a signal is in memory, it can be used to generate sound. Its
|
|
start_samples() function is called for that, and a "sampinfo" block is
|
|
returned; this will contain the current position and any necessary state
|
|
information. render_samples() generates sound, and end_samples() destroys
|
|
the sampinfo block.
|
|
|
|
DUMB's support for existing file formats is implemented as follows. First
|
|
a signal_t is constructed manually by reading the file. Then the special
|
|
make_duh() function is called. This creates a DUH struct with just one
|
|
signal in it, the one we just created. We provide all the above
|
|
functions, except load_signal(), since that has been bypassed. DUMB's
|
|
core now has our start_samples() etc. function for generating the sound,
|
|
and it has our unload_signal() function for getting the file out of
|
|
memory when we're done.
|
|
|
|
It is possible with some sigtypes to adjust their sound using
|
|
"parameters". set_parameter() is called for this. An example would be
|
|
changing the cut-off frequency for a signal that acts as a filter. I plan
|
|
to add a second version of this function that takes a pointer. This would
|
|
be used when manipulating DUHs in code; an example is when installing a
|
|
callback function for a music module file. It couldn't be used by a file
|
|
on disk.
|
|
|
|
This terminology is far from intuitive. Here are some proposals:
|
|
|
|
- The things DUHs are made of can still be called "signals".
|
|
- The types of signal can still be called "sigtypes" ("signal types").
|
|
- The signal-specific data can be called the "sigdata" ("signal data").
|
|
- The sampinfo block can be renamed to a "sigrenderer" ("signal renderer").
|
|
- The parameters can be called "sigparams" ("signal parameters").
|
|
|
|
This way we have some consistency between different parts of the library;
|
|
the API for rendering a DUH as a whole uses the term "renderer". We also
|
|
have a full name and an abbreviation for each term.
|
|
|
|
Any advances on this?
|
|
|
|
---
|
|
|
|
Todo/Wishlist:
|
|
|
|
* MOD/XM loading - change the effect memory system; it isn't robust when it
|
|
comes to remembering stuff from one pattern to the next.
|
|
* --- IMPORTANT --- Put link to IT in docs: http://www.noisemusic.org/it/
|
|
* --- IMPORTANT --- Twist the sample decompression algorithm around, since
|
|
it was derived from a GPL'd algorithm. We don't want
|
|
to have to put it under GPL! :) ... or, find out that it
|
|
wasn't originally written under the GPL and then credit
|
|
the bloke who wrote it :)
|
|
* MMX resamplers and downsamplers
|
|
* Ability to load *.it, *.xm directly into DUH structs (IT done)
|
|
* Ability to embed IT compressed samples... no, it's copyrighted. Let's do
|
|
our own :)
|
|
* Ability to embed ITs themselves (? not sure how useful that is)
|
|
* Remove cit.c
|
|
* Check all return values. I think the Winamp plug-in needs looking at...
|
|
* resample.c - it seems x*y is safe if 0<=x<=65535 and -32768<=y<=32768 or
|
|
vice versa. Check this is true on all compilers. If so, make
|
|
use of it to gain more accuracy.
|
|
* DUMB_IDs should always be long or always be int...
|
|
* Decide whether the load_signal function really needs the DUH parameter...
|
|
* Allow for DUH modularity; different pieces share samples etc.
|
|
|
|
* Fix makefile so it can manage without alld - or put note in the FAQ that
|
|
ppl must build alld
|
|
* Arrange to detect file types by extension (probably not by content though)
|
|
* Change aldmbd to aldmd in makefiles to maintain 8.3 compatibility
|
|
* Put dumb_resampling_quality and dumb_it_max_to_mix in howto.txt
|
|
* More info in howto.txt, in particular that install_sound() is needed...
|
|
* Add a sanity check for restart_position?
|
|
* Note in docs to let entheh know if you release a game using DUMB
|
|
|
|
|
|
STUFF TO FIX FOR THE FIRST RELEASE
|
|
==================================
|
|
|
|
General
|
|
-------
|
|
* Naming is a bit confusing sometimes...
|
|
* What to do about ASSERT() and TRACE() - they were hacked in when
|
|
the lib was split from Allegro, and they need replacing.
|
|
* Add some constants to dumb.h (DUMB_VERSION_STR etc.)
|
|
|
|
entheh
|
|
------
|
|
* Update docs, write more docs (a lot to do here!)
|
|
* Go through, eliminate warnings, resolve some "/** WARNING" comments
|
|
(they used to be #warning but Bob complained :)
|
|
* Program it to calculate the length of IT and S3M files (currently
|
|
always set to 10 minutes IIRC)
|
|
|
|
Bob
|
|
---
|
|
* dumb_resample() now has a volume parameter, so there are some extra
|
|
floating-point multiply ops that could possibly be optimised.
|
|
|
|
tjaden
|
|
------
|
|
* Test on Linux when it's all ready plz :)
|