Re: [AD] Allegro's mixer

[Chris <kcat@xxxxxxxxxx>]

> * The volume no longer decreases as more voices are allocated

> This is only default behaviour anyway.

Both Bob, on IRC, and myself also think the default should be full 
volume. Granted, decreasing the volume per voice is still possible as 
the default, I think it's a bit odd that one would need to call 
set_volume_per_voice(0) explicitly to get full volume.

> > * Samples now clamp to 0 and 65535 without using branching or assuming
> > signed right-shifts; as a result, the output no longer wraps and causes
> > distortion
>
> The output never did wrap and cause distortion, unless you went to something 
> like 4x the volume at which it would be clamped.

Or call set_volume_per_voice(0) and attempt to pan a sample. And the 
original mixer only clamped from 16 bit to 14 bit. After that, it would 
wrap and cause bad crackling.

> If you're doing this, then 
> your distortion is pretty bad anyway and you should reduce the overall 
> volume_per_voice.

Now you can just use set_volume() to reduce volume and any distortion 
introduced by clamping. And the best part is, it can be made to be 
end-user specified. set_volume_per_voice was never meant to be exposed 
to the end-user, yet it had the biggest influence on volume output.

> Just one thing though: is the clamping done after each sample is mixed, or is 
> it done at the end?

In the file I already posted, it's done for each sample. However, I 
fixed it lastnight so it uses a signed 32-bit buffer and only clamps at 
the end.

> That will make the 8-bit mixer more expensive to run - so before we do it, 
> we'd better check that no one has a 386 or possibly a 486 any more :P

Only if you use the high quality mixers. You can still specify quality = 
0 to get the old mixer back. Besides, it's quite possible the hq1 mixers 
are just as fast, or perhaps faster, than the regular low-quality stereo 
mixer now.

> Yes, it was. The parameter to the function is game-specific, and my games use 
> the function. So do put it back in.

Not to worry, I did. :) And at the same time, it no longer needs to be 
called before install_sound. It can be called whenever, and will affect 
the sounds in real-time.

> Unfortunately, this means that just two samples playing at once with volume 
> 255 - or one with volume 255 and panning off centre - will distort. Not a 
> good idea.

Only if their sums can't fit within 16 bits. And the clamping distortion 
is far *far* less noticeable than the old wrapping distortion. And even 
if there is distortion, you can now create an option to let the end-user 
lower the global output if he notices it and is bothered. I think having 
the global output lowered because the buffer _may_ overflow, without the 
end-user being able to do anything about it, is much worse.

> I did want a change ages ago, but people argued with me on the grounds that we 
> shouldn't change the default. So I added set_volume_per_voice() while making 
> sure the default behaviour would always be the same as before.

Well, as I said before set_volume_per_voice() is back in properly, and 
can be made to default to lowering the volume based on how many voices 
there are (which, btw, no longer needs to be a power of two).

> However, there is currently a huge rift between the behaviour of the 
> DirectSound mixer and the Allegro mixer. Developers, please reconsider your 
> position: should Allegro's mixer default to simulating the old Allegro mixer, 
> or should it default to being as close as possible to the DirectSound mixer? 
> Or should the DirectSound mixer try to simulate Allegro's?

I say Allegro's should emulate DirectSound's. The only thing Allegro's 
doesn't do that DS's may (I'm not sure if it actually does) is lower the 
volume when it overflows. I could quite easilly do that, but from what I 
remember of you saying, lowering and raising the volume so fast like 
that would cause clicking and, from my own experience, volume jumping. 
You would have to gradually raise the volume after lowering it. 
Definately doable, but would also put a bigger strain on the CPU, even 
for the low quality mixer unless you just let that clamp. And from my 
experiences, having the SB16 mixer take too long in DOS would cause all 
digital sound to grind and stop permanently, until the program is 
restarted (or the DOS box reopened in Win9x).

> Yep, it would be. I'm wondering if the functions would have been #defines once 
> in the past. Check that there isn't an END_OF_FUNCTION([first function's 
> name]) right at the end after all the functions; I've seen that before in 
> Allegro's source. (Me too lazy to actually LOOK at the source :)

The inline functions in the mixer do not have END_OF_FUNCTION()'s after 
them. Though were they properly inlined, there would be no need to have 
them. Though I do find it odd that -O2 wouldn't inline. Perhaps 
-finline-functions only inlines non-inline code when possible, as has 
been suggested. However, I do know the inline keyword doesn't gaurantee 
your code will be inlined, even if it's small enough to be. And I don't 
see anything with -O, -O1, or -O2 that mentions that code marked inline 
would be inlined.

Anyway, I'll be uploading a new version of the mixer soon after sending 
this mail. http://kcat.strangesoft.net/mixer.c

- Kitty Cat