Channel Statistics

   May 21, 2012
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31

[02:19:06] *** Jonas__ has quit IRC
[02:19:14] *** Jonas___ has joined #openal
[02:19:14] *** ChanServ sets mode: +v Jonas___
[02:26:02] *** Sondiodelsol has joined #openal
[02:26:02] *** ChanServ sets mode: +v Sondiodelsol
[02:38:31] *** Sondiodelsol has quit IRC
[02:45:32] *** Sondiodelsol has joined #openal
[02:45:32] *** ChanServ sets mode: +v Sondiodelsol
[02:49:23] *** Sondiodelsol has quit IRC
[03:29:56] *** jcontra is now known as jcontra-zZz
[04:01:23] *** Sondiodelsol has joined #openal
[04:01:23] *** ChanServ sets mode: +v Sondiodelsol
[04:20:54] *** mat^2 has quit IRC
[04:41:40] <sh4rm4> KittyCat, i am trying to learn how to mix multiple audio channels together. do you know where i could find some info how that's done ?
[04:43:09] <KittyCat> sh4rm4, how do you mean?
[04:43:52] <sh4rm4> well, i have 4 x 8bit audio channels
[04:44:10] <sh4rm4> and i want to mix them together to a single 16bit wave
[04:44:54] <sh4rm4> i suppose there are a few documents that describe this process, but i couldnt find them yet
[04:45:09] <KittyCat> are they the same frequency and channel count?
[04:45:36] <sh4rm4> same frequency, yes
[04:45:41] <sh4rm4> channel count ?
[04:45:48] <KittyCat> mono, stereo, etc
[04:45:57] <sh4rm4> ah, mono
[04:46:25] <KittyCat> unsigned (0..255) or signed (-128..+127)?
[04:46:31] <sh4rm4> signed
[04:47:01] <KittyCat> then you can simply add the samples to mix them together
[04:47:11] <KittyCat> output = input1 + input2 + ...
[04:47:48] <KittyCat> that will give you an 8-bit signed output, but you'll probably want to use a temporary buffer that's an int or something, so you can watch for overflows and underflows
[04:48:35] <sh4rm4> ah, and then multiply the value by 2 and pass it to the audio backend ?
[04:48:38] <KittyCat> to convert 8-bit to 16-bit, bit do a left bitshift by 8.  output16 = input8 << 8;
[04:49:13] <sh4rm4> and when an overflow happened ?
[04:49:27] <KittyCat> clamp to the allowed extremities
[04:49:59] <sh4rm4> someone suggested that using a float for the conversion gives better quality
[04:50:40] <KittyCat> it could I suppose, yeah
[04:51:06] <sh4rm4> it goes like this: 4 channels x 8 bit samples x volume range 0..63
[04:52:22] <KittyCat> output_float = (input1 + input2 + ...) / 128.0f * (volume/63.0f);
[04:52:57] <KittyCat> then output16 = clamp(output_float, -1.0f, +1.0f) * 32767.0f;
[04:53:12] <sh4rm4> 32767 / 16 = 2047
[04:53:12] <sh4rm4> 32766 / 16 = 2047
[04:53:16] <sh4rm4> ...
[04:53:16] <sh4rm4> 32751 / 16 = 2046
[04:54:07] <sh4rm4> if i do the same maths thoug, the multiplication makes the "dynamic range" go away anyway
[04:54:31] <sh4rm4> and if i divide it back by 16, there's no loss whatsoever
[04:55:32] <KittyCat> 8-bit samples have very little dynamic range, so converting 8-bit to 16-bit, then dividing by 16 won't lose any of the original bits
[04:56:55] <sh4rm4> so you dont think it makes sense to do the float conversion ?
[04:57:11] <KittyCat> depends on the quality you're going for
[04:57:18] <sh4rm4> (the point is that i want to avoid the floating point math since the target has no fpu)
[04:59:06] <KittyCat> would be best to avoid floating-point, then
[04:59:59] <KittyCat> where are those instructions from?
[05:00:00] <sh4rm4> i dont know if it's going to be a performance problem. just trying to understand the stuff :)
[05:01:12] <sh4rm4> it's simulating an amiga
[05:01:14] <KittyCat> if you only have 4 input samples, though, I'd think dividing by 16 would be overkill. dividing by 4 would be enough to scale each input so the output won't overflow
[05:03:38] <sh4rm4> i dont quite see why i do have to make that division
[05:04:07] <KittyCat> to prevent the result from being out of bounds for the output
[05:04:59] <sh4rm4> ok lets say we have value 50 at channel 1, 100 at 2, 150 at 3, and 200 at 4 ...
[05:05:10] <sh4rm4> that would sum up to 500
[05:05:40] <sh4rm4> lets say the volume is at 32
[05:06:04] <KittyCat> you couldn't have 150 and 200 for a signed 8-bit input
[05:06:06] <sh4rm4> so i'd do 500 / (maxvol / 32)
[05:06:53] <sh4rm4> ah, true. lets make that 50 and -100 instead
[05:07:52] <sh4rm4> the max i could get is ~512 if all values where at 127
[05:08:55] <KittyCat> when you add two 8-bit samples together, you get an 8-bit sample output, and 512 falls way outside what an 8-bit sample can hold
[05:09:47] <KittyCat> you'd still need to convert to 16-bit, and it would cause an overflow for 16-bit samples too
[05:09:59] <sh4rm4> so i could convert that result into a 16 bit value by shifting it left for 6 or 7 bits
[05:10:25] <KittyCat> 8 bits, yeah
[05:10:55] <sh4rm4> not if i want to support the maximal +/- 512
[05:11:48] <KittyCat> then you'd end up scaling the sample down, just in a round-about way
[05:12:35] <KittyCat> ((input1 + input2 + input3 + input4) << 8) / 4  would be the same as
[05:12:44] <KittyCat> (input1 + input2 + input3 + input4) << 8) >> 2  would be the same as
[05:12:53] <KittyCat> (input1 + input2 + input3 + input4) << 6  would be the same as
[05:13:21] <KittyCat> converting 8-bit to 16-bit, then scaling the result down
[05:14:21] <sh4rm4> hmm but why / 4 and not / (maxvol / currentvol) ?
[05:15:04] <KittyCat> if maxvol==currentvol, then there's no scaling and you'd still risk overflow
[05:15:38] <KittyCat> and maxvol/currentvol won't give you very precise volume scaling
[05:16:14] <KittyCat> sample * maxvol / currentvol  would give better results
[05:16:35] <sh4rm4> oh, indeed
[05:37:16] *** Sondiodelsol has quit IRC
[06:01:18] *** flibitijibibo has quit IRC
[06:01:28] *** sh[4]rm4 has joined #openal
[06:01:28] *** ChanServ sets mode: +v sh[4]rm4
[06:01:58] *** sh4rm4 has quit IRC
[06:14:55] *** flibitijibibo has joined #openal
[06:14:55] *** ChanServ sets mode: +v flibitijibibo
[06:30:53] *** jcontra-zZz has quit IRC
[06:32:10] *** prophile has quit IRC
[06:32:10] *** prophile has joined #openal
[06:32:10] *** calvino.freenode.net sets mode: +v prophile
[07:55:38] *** neXyon has joined #openal
[07:55:38] *** ChanServ sets mode: +v neXyon
[08:20:30] *** neXyon has quit IRC
[09:05:44] *** DragoneneWork has joined #openal
[09:05:44] *** ChanServ sets mode: +v DragoneneWork
[09:13:26] *** thedmd has joined #openal
[09:13:27] *** ChanServ sets mode: +v thedmd
[09:17:22] *** thedmd has quit IRC
[09:26:40] *** thedmd has joined #openal
[09:26:41] *** ChanServ sets mode: +v thedmd
[09:51:49] *** DragoneneWork has quit IRC
[10:35:54] *** neXyon has joined #openal
[10:35:54] *** ChanServ sets mode: +v neXyon
[10:52:04] *** Kaetemi has joined #openal
[10:52:05] *** Kaetemi has joined #openal
[10:52:05] *** ChanServ sets mode: +v Kaetemi
[11:33:57] *** Kaetemi has quit IRC
[11:51:41] *** neXyon has quit IRC


top