Original Post
My game handles music by juggling two stacks. One stack stores pointers to structures that are in an array. Each structure contains the information for one streaming music track. The pointers in this stack are "Free", that is they are not being used for playback right now.
When a song is to be played, a pointer is popped off the stack and pushed onto a second stack, that contains the songs that are currently playing. It''s not a stack in the strictest data structure definition of the term, but I refer to it as that because for the most part it grows up and down in a LIFO manner. Only the "top" playback session on this stack is actually audible. If a song is called to be played while another is already playing (without telling the first one to stop) the first one is muted and the second one starts. This way it will be easy to implement, for instance, a place in the game where level background music will be playing, the player will enter a dialogue session which requires a different tune to play, and then the first song can pick up right where it should be. When the song finishes it is popped off the "playing" stack and goes back on top of the "free" stack. The exception to the stack nature of the playing set is that a song may actually finish up while it is not the audible song. In this case it still has to free itself up by getting back to the free stack. Songs can loop too, in which case they never "Finish" unless told to do so.
Music decoding is done by seperate threads. When a song is started, a new thread is created that manages the data structure for that song, including periodic calls to decode buffers before queueing them up to be played in order. The thread then takes a break via Sleep() for roughly the amount of time it takes a buffer to play so that the rest of the program can get some work done. [bold]What is a good size for such a streaming audio buffer, and how many should I maintain?[/bold] Presently I have it set at two buffers of about a second of audio (44.1khz, stereo 16-bit for music) Although right now the music works with RAW files, I plan to eventually implement OGG Vorbis format reading if only because RAW format songs can be gargantuan files.
(TLDR version begins here)
Now why have I presented this novel of a description, short of inviting criticism? For one thing, I like to think that if I can (or try to) explain something I''ve come up with to another person (or people) that it makes it clearer in my mind and also helps me sometimes answer questions before they arise.
ability of sources to move and fade with distance to accomplish fading, but this presents some timing issues, such as knowing
My first question deals with transitions between songs. When a song is started while another is still playing, a parameter indicates whether the songs should crossfade or if the new one should just start right up while the old one stops instantly. Presently my fade procedure involves manually scaling samples as they are decoded for the duration as the fade. This works well so far, but it seems a bit kludgy and slows decoding during the fade. I am using OpenAL for my audio and my original plan was to use relative-to-listener sources for my music and use the exactly when and how to "stop" the source from moving. [bold]Is there an elegant way to fade an OpenAL source over time?[/bold]
), and i think you could get a crossfade going by having one song come from one source, one song come from another (you must already do this). then just have one's gain go up, the other's go down. the (slightly) tricky part is AL_GAIN is also the volume control for sources, so you ahve to make it fade between 0 and the current volume.