[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Is there no reasonable heuristic to deal with the clipping issue? Like, if
you knew what the maximum range of a group of 5 samples was, you would know
what volume would guarentee no clipping? Or would guarentee it some
percentage of the time?
Is it possible to do some analysis of the samples to deal with this issue
automatically?
-----Original Message-----
From: alleg-developers-admin@xxxxxxxxxx
[mailto:alleg-developers-admin@xxxxxxxxxx Behalf Of Chris
Sent: Monday, May 17, 2004 6:00 PM
To: alleg-developers@xxxxxxxxxx
Subject: Re: [AD] Sound API
Ben Davis wrote:
> On Monday 17 May 2004 14:16, Chris wrote:
>
>>>What about for DUMB's example players? They want to use a single audio
>>>stream, stereo panned and centred, and have the output at maximum.
>>>set_volume_per_voice(0) is required here.
>>
>>It's an example player, meant as an example. As I said, how often is
>>set_volume_per_voice(0) useful for games?
>
> Whenever I want a single stream, centre-panned, to be able to reach the
> maximum.
Which is how often for a game?
> My argument was that the DX mixer should be kept for a while for
emergencies
> and should no longer be the default. I know full well that it ignores svpv
> and so on. As soon as we're sure that the Allegro mixer (and its interface
to
> the hardware) works well for everyone on Windows, the DX mixer can go.
Unfortuantely, as long as the DX mixer is in, I can't apply my patch due
to the mixer streams not working at all under that driver. Unless you'd
think it's alright to leave the mixer streams in and just not expose
them yet..
> Most users will naturally reach for the volume control on their speakers,
> which obviously won't solve the problem. The game developer has to take
some
> responsibility; if someone sets a ridiculously high value with
> set_volume_per_voice(), that's their fault. We can't be removing a much
used,
> and very useful IMO, feature just to try to save the game developer a bit
of
> responsibility.
Well, I'm not saying to out and out remove it. Just to discourage its
use. You're right, the game developer has to take a bit of
responsibility to make sure output volume doesn't clip too much, which
is exactly what a default volume level would do. Most games will do fine
with a volume level of 70% to 80% (if I remember hearing this
correctly), whereas Allegro defaults to (100/num_voices)%
>>Nothing's preventing a program from implementing a default volume that
>>the programmer safely feels accomodates the voices. I feel that's a
>>better method than relying on the max voice count to limit voice volume.
>
> But we're not relying on the max voice count; that's only the default.
That's the default, which is why you're relying on that, unless you can
be sure most people who write programs with audio will set a reasonable
set_volume_per_voice setting (and given that most use the DX mixer, you
can probably be reasonably sure most don't bother with it).
> If it's
> set, we're relying on the parameter to set_volume_per_voice().
Operative word being "If".
>>I can, yes, but except for the default setting for set_volume_per_voice
>>I can't say I agree with it. And if memory serves, even Bob agreed (on
>>IRC) that he'd like the default set_volume_per_voice raised now that
>>warpping isn't an issue.
>
> Would I be right in assuming you mean "as for" rather than "except for"?
Either way, both get my point across. I can emulate (which it isn't
really, it's still a proper implementation of set_volume_per_voice, IMO)
the behavior of the function, but I can't say I agree with leaving the
default as-is.
>>>In the long-distant past, Allegro always made samples quite quiet (a
>>>centred sample would be one quarter of the maximum volume), and made them
>>>even quieter if you requested more voices. This was someone's decision,
>>>and would be appropriate sometimes, but is too quiet for a lot of cases.
>>
>>Which is exactly my point to raise the default. It's too quiet most of
>>the time and makes people think the Allegro mixer is inferior because of
>>it. I can't pretend to know Shawn's true intention for limiting the
>>voice volume by default, but if I had to guess I would say it's because
>>the possiblity wrapping was too great, which is no longer true (let
>>alone possible) with my patch.
>
> So how about a compromise: raise the default but make sure any program
that
> calls set_volume_per_voice() will behave the same as before?
Any program that uses that function will behave just like before. 0 sets
the volume to double, 1 sets it to normal, 2 is half, -1 accomodates for
all allocated voices, just like the default does now in the mixer. I
just believe the default should be 1, and the function's use should be
discouraged for more flexible methods.
> I don't know what you did, but I, as a _game developer_ (not an end-user),
> hacked Allegro for the purposes of building binaries for a couple of my
> games. set_volume_per_voice() meant I no longer had to do this.
As a game developer, there's no reason to hack Allegro unless you're
going to distribute the hacked library. I, as an end-user and game
developer, hacked Allegro so the audio output in the programs I play
that use it aren't so quiet as to be inaudible. I'm just saying that
with set_volume_per_voice, those hacks are useless since I now
potentially need to hack each program that uses the function.
> If you download my game and you want it to be louder, you should turn your
> system volume control or the knob on your speakers up.
I don't have any volume knobs on my speakers, and I have my system's
mixer settings set to (what I believe to be) optimal levels for my
computer's normal usage. If I play XMMS or something and think the
output is too quiet (which is built from many factors, including ambient
noise elsewhere in the area), I temporarilly increase the sliding bar to
increase the volume, not hack the source and recompile.
>>I don't agree. I don't see any reason for the programmer to be able to
>>say "you can't go above this volume level because I think it's bad"
>
> I don't see why we're asking for Allegro programs to be able to go so much
> louder than all the other programs out there.
How many programs use some kind of functionality like
set_volume_per_voice? Most games have fluctuating voice volume (based on
distance and direction), so each voice would have a different volume.
> With set_volume_per_voice(),
> Allegro games will all generate roughly the same overall output level
(unless
> the game developer is an idiot), and it will be the same output level as
all
> the other programs on the system.
I don't see anything with set_volume_per_voice that can't be
accomplished with set_volume.
set_volume_per_voice(x) = set_volume(256>>x, -1);
> If set_volume_per_voice() is wrong because it takes a choice away from the
> user, should we also remove GFX_AUTODETECT_FULLSCREEN and
> GFX_AUTODETECT_WINDOWED from Allegro?
No, because those are easilly configurable in allegro.cfg.
set_volume_per_voice is not at all configurable by the end user.
>>(this isn't even touching the fact that the library currently sets an
>>extremely low volume level by default because it feels it's bad to go
>>over it, and that the programmer has to actively add extra code, though
>>granted only one line, to override this). If the program has a risk of
>>distortion, the programmer can set the default volume to something he
>>deems reasonable, but the user should be able to go above this if he so
>>chooses. I don't see any reason not to do it that way.
>
> Apart from backwards compatibility and the fact that the volume level only
has
> 8-bit precision.
I don't think precision's an issue with the current API. The function
will continue to exist as it does now, and I'm just saying its future
use should be discouraged.
- Kitty Cat
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
--
https://lists.sourceforge.net/lists/listinfo/alleg-developers