Re: [AD] Sound API attempt

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

Cross-posting response from ACC:

On Monday 16 May 2005 07:39, Chris wrote:
> A very basic beginning can be found here:
> http://kcat.strangesoft.net/sound.c
> 
> It is in no way, shape, or form suitable to be put into the new api 
> branch, but I hope it's good enough to show that there is /soemthing/ 
> being worked on. Questions, comments, and concerns welcome.

Looks good!
I have one question and one comment/suggestion/request/demand;).

The question is about the number of bits and signed-ness of the sample. You 
use defined flags for the sample format. As was pointed out recently, we 
probably also have to deal with 24 bit and, possibly in the future, higher 
precision. This means we will need to add the bitflags for that. Not a big 
deal as far as the exposed API is concerned, but slightly awkward and not 
very pretty internally. Would it be an idea to use a variable to store 
this information rather than encode it in a bitfield? Say, if 
sample_format=8 it means 8 bit unsigned, if sample_format=-16 it means 16 
bit signed and so on.

My comment/suggestion/request/deman;) is for the naming of internal static 
functions. Allegro uses (a variation on) al_verb_noun for its public API, 
all lower case and with underscores. Using MixedCaps for internal 
functions isn't a big deal because, well, it's internal, but it still 
makes the code slightly more awkward to read. In the interest of coding 
style consistency I want to ask you to change the internal functions to 
that coding style too. I can do it when commiting the patch, but it saves 
time if you do it. ;)

Evert