intfiction.org

In theory there should not be too much variation between Glk libraries. The Glk specification says, with regard to the glk_schannel_set_volume() call:
The question then becomes what exactly is meant by a phrase such as "half volume". I would take what I hope is a common sense position on this: if a game plays a sound at half volume and I have my amplifier volume dial set to (say) 8, then it should have the same perceived loudness as when the game plays a sound at full volume and I have my amplifier volume dial set to 4.

When talking about perceived loudness, the usual rule applied (see for example http://www.sengpielaudio.com/calculator-levelchange.htm) is that a -10 decibel change in volume is equal to a halving of the perceived volume. This is what Windows Glk does: it uses Windows' DirectSound interface to play sounds, and a call to the Glk volume function with a volume of 0x10000 causes DirectSound to be set to a volume of 0 dB; a call to the Glk volume function with a volume of 0x8000 causes DirectSound to be set to a volume of -10 dB; a call to the Glk volume function with a volume of 0x4000 causes DirectSound to be set to a volume of -20 dB; and so on. I don't know what the other Glk libraries do but I would hope it would be something similar.

Gargoyle does a linear conversion of the volume parameter into the SDL_mixer level, which ranges from 0-128.



Based on your numbers it seems like the results should be similar, but reports from the field suggest otherwise.

What I don't know is whether SDL_mixer amplifies the volume, and if so how to calculate the zero point of the unadjusted volume. Maybe 128 is not linked to the sound file at all but represents the highest volume the system can output? Then two sounds with different volumes would have the same apparent loudness if both were played at 0x10000.

I guess I need to do some testing.

It does not use the system's mixer. It alters the sound by itself, before the final mixing step. MIX_MAX_VOLUME (which is defined as 128) means "don't touch the sound" (in other words, a 0db attenuation).

Good to know, thanks NC!

It looks like I can get volume changes broadly similar to WinGlk's by using a logarithmic approach instead of a linear one. I'll get that fix merged in for the next release.

That would be good, but in doing this I suspect you'll need to look into what SDL_mixer does with its volume argument. Looking at the documentation for SDL I couldn't see anything that explained what it does: is it a linear scaling of the waveform data by the volume argument?

Yes, you are right. Both.

I will publish a beta version of DamusixI7 just finished my internship (in 2 weeks more). After that, I guess I will take about two to three weeks to have a working version ready and tested (given the recent changes in I7, and the release of the next Damusix 4, more user-friendly for English-speaking).

I take this time because I have had many changes this quarter: my internship, moving to a new home, moving to a new operating system (now I'm using Linux ), etc.

Thank you for your support.

PS: The "abuse" I promised, I will try to publish it in 1 week more. I have not forgotten it.

_________________
Eliuk Blau
eliukblau (AT) gmail.com
http://www.caad.es/eliukblau/

Sorry, I let this thread slip away from me...



In this case, I want to make features available *efficiently*. The fact that they can be approximated in VM code at the cost of rapid timer-looping is not a reason to skimp on the Glk API level. If the result is that a future version of Damusix provides the same features, but produces a cleaner compiled game, that's still a win.

Now, Ben's earlier point *is* a concern:



That's a significant cost and I don't want to impose it without good reason.

Let me ask this: do you already have a callback that takes buffers of sound output from SDL_mixer and passes them to the OSX sound library? If so, it might be better (and produce a better result) to scale each buffer as it goes by. That way, the volume during a change would change smoothly rather than being stairstepped by any timer at all.

The code to scale a buffer by a linearly-changing factor is very simple -- I've written it a couple of times for other projects. (It would be harder if there were multiple volume changes going on at the same time, but I've explicitly ruled that out.)

This is basically equivalent to multiplying the raw waveform data by V/0x10000, right?

This is where, as far as my limited understanding goes, things get difficult: I have a nasty suspicion that the above, while seeming obvious on the first glance, is not in fact correct.

When talking about sound volume, we could be talking about one of three things: the power in the sound wave, the amplitude of the sound wave (which would be the definition used by you in the above) and the perceived loudness. None of these three are equivalent. Most sound libraries' documentation dodge this issue by not specifying what is meant by volume. The Microsoft DirectSound SetVolume documentation is as bad as any other in this: there's much talk of decibels, but no talk of what precisely the volume argument applies to.

If this sounds like I'm generating problems without offering solutions: I am. Sorry about that.

I have something similar: a callback that queues up a new sound buffer for SDL_sound to play (via SDL_mixer, which masks the OS interface).

The trouble with using the SDL_sound callback to handle volume change is that that the buffers are somewhat large - 128 KB - to minimize the processing / decoding overhead. This code path is used for Ogg / MP3 at the moment but could be extended to the other sound types.

The 128K size is somewhat arbitrary; I had Eliuk run a lot of tests using different buffer sizes and that's the one he liked best. I think it works out to be 1-2 seconds of audio per pass, which is a bit coarse for the proposed API. I could tune it to a lower amount at the cost of performance and audio quality.