| Re: [AD] Allegro's mixer, update |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Elias Pschernig wrote:
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.
Originally, using 8-bit audio meant that you'd always get the low
quality (0) mixer. However, since there was no bitdepth dependance in
the mixing code I made it so 8-bit can use any quality (including
interpolation) and just downsample it when it's sent to the driver, like
has always been done (I also made it so 8-bit audio can be sent signed
if the driver so requests). It's also good to see the interpolation
mixer didn't get much of an impact despite using some 64-bit math (btw,
thanks Ben!).
Those numbers are pretty encouraging in that the low quality mixer is
obsolete, though. I'll run the test program myself, but if it holds
true, I would like to remove the low quality mixer (and change the mono
mixer to use the same algo as hq1, obviously I wouldn't remove that).
I actually have no idea what exactly I was timing though.. maybe just
the transfer from Allegro to ALSA :)
Those numbers do seem to indicate it was, in fact, the mixer. Or at
least influenced by the mixer. :)
I've added these self-explanitory functions:
They still should get well documented (once your patch is in). I have
seen enough "self-explanatory" functions in the Alsa docs :P
Of course. :P But as you noted in the other email, that's for when (if?)
the patch gets aproved (it's still not done, don't forget).
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"?
I suppose I could with some work, but mixer streams are a bit simpler
than voices. With voices, you can loop and specify volume/pan ramps and
stuff. With mixer streams, you just send audio data to the card as-is.
If you want to ramp the volume, pan, or frequency you have to do it
yourself. If you want to loop, you have to keep sending the mixer stream
the same data over and over again (and in the case of backwards and
bidirectional, you have to supply the backwards data yourself). Granted
it can be done, and was what I meant in saying that mixer streams could
take the place of voices, it would take a bit of work. This is just the
foundation work. Things can be built on top later after it's matured
some. :)
Again, for a user, they aren't self-explanatory at all.
Quite right. I'll be sure to write proper documentation before I'd call
it "final".
// 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?
mixer_stream_is_ready? I dunno, for some reason the "is" looks a little
out of place.. probably the same reason Bob didn't really like the "to"
in the next function.
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?
Yes. And you can't modify it until it's flushed out (write, check,
write, check; when the second check clears, assuming you passed a
different buffer the second time, the first has been gauranteed to be
released).
There still could be some pre-allocated ones for voices..
When they replace voices, that's true. Though there could also be an
initial cache of pre-allocated mixer streams too.
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?
Except for output volume (which now defaults to not decreasing volume
voices as more are allocated at program start; you'll definately notice
this if you use DIGMID) that can max out at 16-bit, instead of 14, and
the fact that you won't get any sample wrap even if you play 255
simultanious voices at max volume (previously it would you you played 4
or 5 voices at max volume), as well as better volume/panning precision,
24-bit interpolation, and general 24-bit precision (the latter three
possibly not being too noticeable due to the 24->16/8 conversion), you
might not hear a difference. It greatly depends on your speaker set,
too. However, the mixer is a lot cleaner now IMO, and can be extended
easier (24-bit samples/output, 3+ channels, ect). Extending it would
require some changes elsewhere in Allegro too, but the mixer is more or
less ready for it.
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.
Do we still have to follow that, as long as the code is still readable?
It's well known that Allegro is a community-type project with many
different coders, and as long as the code is readable and clean, does it
matter? The AHG was written when Shawn was "the man" behind Allegro,
AFAIK. Everything went through him and he personally looked it over and
tested it. It's no longer that way, so do we really need to follow it?
Granted I haven't looked at the AHG in a while and I don't know what
else it says, but I think it's generally excepted that coding style can
change slightly from person-to-person. It's hard enough for me to read
Allegro's code with its indentation method, let alone write it. If you
really need me to, yes I can do it, but it just doesn't seem like
something that should be important.
Though if nothing else, can't we at least make an exception for indent
== tab stop without 4 indents == 1 tab? The size of the tab stop
wouldn't matter since that's different on everyone's computer, so I
could tab and see 4 spaces, you could see the tab at 8 spaces, and
someone else would see it as 3, depending on how they want it.
Oh yes, and there's something I seem to have forgotten to say in the
last email. I originally wrote about it, but I lost that email due to
Thunderbird crashing and forgot to write it again when I rewrote the
email. Because the mixer streams, and the updated mixer obviously,
require Allegro's mixer, they won't work or be noticed without Allegro's
mixer being active. AFAIK, there is only one driver that completely
skips it, and that is the DirectSound mixer (ironically, the one most
used). Forgetting the fact that I think that should be removed (replaced
transparently with the one that still uses Allegro's mixer) until proper
hardware voice management can be done, a simple fix would be to reserve
1 DX voice to play Allegro's mixer on. The simplest way would be to just
allocate one more voice and tack it on to that, though the "correct" way
would be to put it on the last allocated voice, and when the program is
requesting to allocate the (already allocated) last voice, it just hands
it off to Allegro's mixer where it'll get mixed into the last voice
properly.
- Kitty Cat