I didn't think about a destructor, which could come in handy after all when destroying the stream.
One question arises thou: internally the struct has a member void *extra, which is currently used and I assumed that IF allocated (i.e. != NULL ) would have al_free called on it upon destruction.
Were I wrong assuming it?
Right now I've added the two functions but I am merely adding the 'extra' as a pointer to a WM_FILE_DATA struct that very much resembles WAVFILE, FLACFILE, etc...so a dtor is not strictly needed. I'll try to experiment a bit, if you like I can make a PR to have the code availble for review, though it's DEAD SIMPLE.
About your observation, I tend to agree that exposing the common interface for on-demand load could be useful, along with being able to register new handlers just like the loader....but I admit I haben't yet tooled around with the addon enough to have a well-informed opinion; gut feeling is that's a sensible proposal.
EDIT: I just realized that I can't access also the stream mutex with the API...damn...
How should I go then for a proper feeder thread?
Without thinking too much of it, it might be nice to also specify a destructor alongside this pointer?
I've dabbled a bit with the two functions, could you please explain me how should I handle the destructor passign along and such?
Is there something like _al_register_destructor internal function? (I ask cause none is documented).
I've succeeded into expanding the API with:
and implemented a WildMidi loader which can be registered into Allegro interface and auto-feeds the stream.
It can be found here for peer-review, even thou I fear I'll be an embarrassment to myself
Anyway I ran into some problems, that persist and that shed some light on what Siegelord wrote above (I didn't understand fully at the time, I guess).
The stream internal are quite elaborated and passing a userdata pointer to manage the extras seems inefficient and incomplete.
For example, I correctly register my functions into Allegro interface through al_load_audio_stream and it starts the auto-feed thread, BUT I don't have means to signal the thread itself to stop if I call al_destroy_audio_stream
In the test executable it's not a problem but I know this is unacceptable, I will have to find a way to register an *extra destructor that handles the signal for me (by the way, if anybody could suggest HOW, as I asked above, I'd appreciate ).
Seems a waste, since al_destroy_audio_stream ALREADY does that for the internals.
I think that the stream API might benefit from a larger exposition of the stream's structure, at least for the feed thread and such.