Re: [AD] Allegro's mixer, update

[Elias Pschernig <elias@xxxxxxxxxx>]

On Tue, 2004-04-13 at 03:49, Chris wrote:
> I've continued work on Allegro's mixer (despite having no access to my 
> comp for two week due to moving). The mixer itself is about as done as 
> I'm gonna do, probably. Though I would ask if the low quality mixer is 
> still required. It doesn't seem likely that there's a noticeable speed 
> gain, and it would be nice to remove 4 functions that look almost 
> identical to the 4 right after them. Unfortunately I can't test the 
> mixer speeds myself as the profile version of Allegro seems to crash (it 
> seems to be associate with calling _mix_some_samples too quickly). The 
> debug and optimized builds are fine though, so I don't know what's up 
> with it.

Well, profiling works here, but the times all show 0 - probably because
I don't know how to use it. I did some simple timing with bash though:

OLD         NEW

8 bit 44100 Hz stereo ALSA
0: 2200 2230 | 2220 2210
1: 2210 2200 | 2210 2220
2: 2210 2210 | 3060 3060

16 bit 44100 Hz stereo ALSA
0: 2210 2230 | 2210 2210
1: 2560 2570 | 2210 2220
2: 3040 3050 | 3060 3060

OLD is 4.1.14 cvs, NEW is with your patch applied. The 2 values are just
2 different runs. Interestingly, the only difference I get with 8-bit is
with quality 2, where the new mixer takes much longer. With 16bit,
quality 1 got faster, quality 2 slightly slower.

I actually have no idea what exactly I was timing though.. maybe just
the transfer from Allegro to ALSA :) My test program is here:
http://allefant.sf.net/allegro/mixertest.c
And the numbers are produces by running, in bash:
time ./mixertest
Then I took the "user time".

>  I've added these self-explanitory functions:
> int get_mixer_buffer_length(void); <-- Returns # of samples per channel
> int get_mixer_voices(void);
> int get_mixer_bits(void);
> int get_mixer_channels(void);
> int get_mixer_frequency(void);
> 

They still should get well documented (once your patch is in). I have
seen enough "self-explanatory" functions in the Alsa docs :P

> I've also added new functionality that I would hope could be part of the 
> exposed API, though generally used through audio streams, which can sit 
> on top of this. I've added mixer streams that allow you to pass 
> formatted audio data right into Allegro's mixer. They don't rely on 
> looping voices, ala audio streams, and don't count towards the total 
> voice count. They're sort of like a mix between audio streams and 
> regular voices, though I'd like to think they could take the place of 
> both.

Hm, so now we have streams, voices, mixer_streams. This needs a lot of
clarification in the docs - since I'm confused to be honest (but I don'T
know the internals of Allegro's mixer). Couldn't you just modify voices
to be "mixer streams"?

>  The only thing they can't do automatically, like voices, is 
> automatic looping. Proper manipulation of data can emulate looping 
> though. Mixer streams are designed to run on a poll-like system, though 
> a seperate timer should be able to automate them just fine. Here's some 
> of the self-explanitories:
> void set_mixer_stream_freq(MIXER_STREAM *mixer, int freq);
> void set_mixer_stream_volume(MIXER_STREAM *mixer, int freq);
> void set_mixer_stream_pan(MIXER_STREAM *mixer, int freq);
> // Those set_* functions have get_* counterparts.
> int get_mixer_stream_position(MIXER_STREAM *mixer);
> 
> MIXER_STREAM *create_mixer_stream(int bits, int channels, int freq, int 
> vol, int pan);
> void destroy_mixer_stream(MIXER_STREAM *mixer);

Again, for a user, they aren't self-explanatory at all.

> // These two should probably be renamed, but I can't think of names.
> int poke_mixer_stream(MIXER_STREAM *mixer); Tells if the stream is ready 
> for more data

is_mixer_stream_ready maybe?

> int write_to_mixer_stream(MIXER_STREAM *mixer, void *buf, int len); 
> stores the buf pointer to copy into Allegro's mixer; len is # of samples 
> per chan

So, you have to keep the buffer around after you call this?

> 
> As you can see, it deals with pointers instead of indices. Since there 
> can theoretically an be unlimited number of streams allocated (if not in 
> use), I felt restricting the number via an array unnecesary. It does 
> mean though that they can't be allocated in time-sensitive areas like 
> voices (deletion is fine since that's done in the mixer thread).
> 

There still could be some pre-allocated ones for voices..

Oh, and, btw, can you provide a small example where I can hear the
difference to the old mixer? I played some games, but they sound the
same to me, and clipping occurs at the same time. Should this have
changed in any way?

> Anyway, here's the diff. Apply it to the original 4.1.13 mixer.c.
> 
> ______________________________________________________________________
> --- mixer.c.orig	2004-03-21 02:08:54.000000000 -0800
> +++ mixer.c	2004-04-12 02:14:12.000000000 -0700

Hm, didn't read it, since I don't understand it anyway. But you really
have to use Allegro's coding style. Read the section in the docs
"Allegro hacker's guide". I agree that it uses a very weird format - but
all the code uses it, and there will always be someone who prefers
another format. Specifically, indentation is 3 chars, tab stops are 8
chars.

-- 
Elias Pschernig <elias@xxxxxxxxxx>