Maes
I like big butts!
Posts: 8664
Registered: 07-06 |
Exactly how often/rapidly is the audio engine in Doom games supposed to react to the submission of new sound sources and the status updates of existing ones? Ideally, since updates are submitted after each (real) tic, it should in theory be able to react as fast as the standard ticrate of 35 fps.
By examining the linuxdoom source code however, I found two quite conflicting/unclear and indirect definitions of the "audio sample rate". From isound.c:
code:
// Update all 30 millisecs, approx. 30fps synchronized.
// Linux resolution is allegedly 10 millisecs,
// scale is microseconds.
#define SOUND_INTERVAL 500
OK, so a period of 30 millisecs would give an audio update rate of nearly 33 fps. Not exactly 35 fps, but reasonably close. However that "500" number seems arbitrary, and I don't see how it could be used to generate a period of 30 ms (unless it's in the time units of a particular timer chip?)
However the mixing routine in sound.c defines this as the smallest audio buffer length that can be processed (presumably without it being interrupted and without the channel data being altered during mixing):
code:
// Needed for calling the actual sound output.
// Needed for calling the actual sound output.
#define SAMPLECOUNT 512
#define NUM_CHANNELS 8
// It is 2 for 16bit, and 2 for two channels.
#define BUFMUL 4
#define MIXBUFFERSIZE (SAMPLECOUNT*BUFMUL)
#define SAMPLERATE 11025 // Hz
#define SAMPLESIZE 2 // 16bit
In particular, SAMPLERATE/SAMPLECOUNT = 21.53 which means that in a single second, there can be only 21 complete and unique sound buffers gettting mixed, if each is 512 samples long (to achieve a rate of 35, they would have to be smaller, closer to 315 samples per buffer).
If synchronous sound update is forced after every tic, then at a rate of 35 fps there will be 17920 samples mixed per second (instead of 11025), leading to excessively fast mixing which will have to be dropped/sound weird.
These problems affect mostly synchronous mixing if you are doing your own sound mixing, of course, but can also affect asynchronous sound servers to a degree, depending on what is their minimum sound "chunk".
These discrepancies and the lack of a clear guideline made me adopt an adjustable "audio rate" model in Mocha Doom's new sound engine, so that SAMPLECOUNT=SAMPLERATE/AUDIO_RATE, combined with a forced timer that decouples the sound engine from the rest of the program, essentially working as an internal audio server/pseudo-interrupt system.
Of course, the linuxdoom code is not the best way to draw conclusions about sound, but isn't the linuxdoom mixing routine actually used in vanilla, with DMX doing only the output? If so, with what parameters for buffer size, interval rate etc?
Also, exactly what approaches are used in other source ports? Is the sound rate controllable/controlled or it's something left to the implementation of the sound library being used?
|
08-26-11 12:18 
