gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Audio > how many PCM sounds can be played simultaneously on GBA?

#1823 - rome - Thu Jan 23, 2003 7:18 pm

i?m very confusing about direcsound channels.

if gba has 2 channels (directsound a and b) then is possible to play only 2 PCM (wav) sounds on GBA device??

#1824 - Vortex - Thu Jan 23, 2003 7:43 pm

It is possible to play more that one sample per channel, but you need to implement some kind of mixing in your code.

#1825 - tepples - Thu Jan 23, 2003 7:47 pm

It's possible to play several sounds simultaneously on the GBA. You just have to mix them in software. The two DSound channels are mainly intended to be the mixer outputs for the left and right speakers.

That said, if you don't have much else to do in your game other than mix samples, such as a 2D platform game or a puzzle game or anything else with simple graphics, physics, and AI, a good software mixer can mix 30 or so channels in mono or 16 channels in stereo.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#1858 - snug - Fri Jan 24, 2003 5:06 pm

On the topic of software mixing, does anybody know of some good software mixing tutorials geared towards the AGB?

#2320 - regularkid - Sun Feb 02, 2003 2:19 am

I too would be very interested in a software sound mixing tutorial! Anyone?
_________________
- RegularKid

#2325 - col - Sun Feb 02, 2003 3:03 am

This is not gba specific, but it covers most of what you'll need to know.

Just apply the approach discribed here to the gba hardware.

And heres a tip to get you started, gba hardware wants signed twos complement 8bit samples.
However its easier to mix unsigned 8bit samples, so convert them right at the end of the process using your 'volumetable'

http://www.oxygen.it.net.au/mixing/


cheers

col

#2326 - tepples - Sun Feb 02, 2003 3:16 am

Here are the basic ideas behind the mixer in TOD milestone 3 (in progress; I still have four bugs blocking its release).

First, you'll have to get the PCM channels going in the first place, playing one sound at a time. You'll have to convert your wave files from .wav format (unsigned 8-bit PCM, signed 16-bit PCM, or something compressed) to a format the GBA understands (signed 8-bit PCM). Read these tutorials to get started.

Then figure out how to change the audio start address every vblank (turn off the DMA channel, set the source address, turn the DMA channel back on).

Then figure out how to write ARM code and put it in IWRAM.

Then play sounds by copying pieces into two small buffers in IWRAM. Start one buffer playing and copy into the other; this technique is called "double buffering". Because the GBA runs 280896 cycles per frame, you'll have to pick your sample rates carefully. A good one to start off with is 924 cycles per sample, 304 8-bit (signed char) samples per buffer. Make sure to do something sensible when the sample's length is not a multiple of your buffer's length, such as cutting off the sample (setting its rate to 0) or looping part of the sample (subtracting a constant from the source pointer). You'll need to compile this rudimentary mixer as ARM code in IWRAM.

Then learn fixed point arithmetic.

Then figure out how to change the volume of a sample (hint: multiply each byte by a constant 0-255 and then shift right by 8).

Then figure out how to change the pitch of a sample (hint: treat the pointer as a fixed-point number, and add a constant to it every sample).

Now here comes the hard part. Make a third buffer with the same number of samples as your other buffers but 16 bits deep (use the 'signed short' type). Instead of changing volume and pitch directly from a sample in ROM to the buffer in IWRAM, add it to your buffer. The steps of your algorithm should look like this:
1. Clear the buffer to all zeroes.
2. For each voice being mixed, add it to the buffer. Don't shift right when changing volume; you'll do that at the end.
3. Now copy the buffer on top of the 8-bit buffer, shifting each sample right 8 bits. (Truncating the final mix rather than each sample results in less noise.)

Now put each sample's information in a struct, and you'll be able to do more than one voice.

Of course, an optimized mixer is a bit tougher. You'll need to 1. unroll the loop slightly and 2. recognize common special cases and write "fast paths". It's possible to get a mixer down to 2.5% + 2%/voice CPU usage for 18 kHz mono mixing using only C compiled to ARM with GCC and no assembly language.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#2328 - tepples - Sun Feb 02, 2003 3:25 am

col wrote:
However its easier to mix unsigned 8bit samples

How do you figure? Is unsigned multiplication faster than signed multiplication? And how do you correct the "bias" for waves that end halfway through a mix buffer? Currently, I'm mixing signed samples at 2.5% + 2%/voice at 18 kHz mono using only C, and that's with variable volume, pitch, and looping.

Quote:
so convert them right at the end of the process using your 'volumetable'

Though a table sped up post-processing on the 486 and 586 because they lacked conditional move instructions, post-processing on an ARM processor is probably faster with code than with a table stored in EWRAM or ROM.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#2333 - col - Sun Feb 02, 2003 3:56 am

tepples wrote:
col wrote:
However its easier to mix unsigned 8bit samples

How do you figure? Is unsigned multiplication faster than signed multiplication? And how do you correct the "bias" for waves that end halfway through a mix buffer? Currently, I'm mixing signed samples at 2.5% + 2%/voice at 18 kHz mono using only C, and that's with variable volume, pitch, and looping.


I don't think that the way i'm mixing will work with twos compliment signed... I'll have another look though - might be wrong...
As far as specs go, I'm getting 8 channels panned mono(256 positions) pitched with volume @ 18k mixed down in about 14.5% cpu per frame (in ARM assembly)

tepples wrote:
Quote:
so convert them right at the end of the process using your 'volumetable'

Though a table sped up post-processing on the 486 and 586 because they lacked conditional move instructions, post-processing on an ARM processor is probably faster with code than with a table stored in EWRAM or ROM.

The table is in iwram, and allows non-linear volume clipping with no overhead!

cheers

col

#2336 - tepples - Sun Feb 02, 2003 4:11 am

col wrote:
I don't think that the way i'm mixing will work with twos compliment signed

ldrsb is your friend.

Quote:
As far as specs go, I'm getting 8 channels panned mono(256 positions) pitched with volume @ 18k mixed down in about 14.5% cpu per frame (in ARM assembly)

Is that with or without looping? Without looping, I'm doing 8 voices in 14.5% cpu (35 scanlines) as well, but with no support for panning.

Quote:
The table is in iwram, and allows non-linear volume clipping with no overhead!

How big is it? Some programs need a mixer with a small IWRAM footprint because they're also running graphics code.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#2337 - col - Sun Feb 02, 2003 4:35 am

tepples wrote:
How big is it? Some programs need a mixer with a small IWRAM footprint because they're also running graphics code.


all in - code buffers tables etc it's about 4.6kb of iwram - with some trickery, i think i can knock that down to around 4k

please explain what you mean by looping?


cheers


col

#2339 - tepples - Sun Feb 02, 2003 4:39 am

col wrote:
please explain what you mean by looping?

Often, a wave will have attack and decay, and then the last n bytes of the wave are repeated as a sustain until the channel is silenced.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#2340 - jd - Sun Feb 02, 2003 5:23 am

tepples wrote:
Currently, I'm mixing signed samples at 2.5% + 2%/voice at 18 kHz mono using only C, and that's with variable volume, pitch, and looping.


Not being one to brag, but I've managed 0.5% + 1.1%/voice at 24 kHz with variable volume, pitch and looping with ~2K of IWRAM usage. As you can probably tell, I'm pretty chuffed. :)

#2342 - tepples - Sun Feb 02, 2003 6:35 am

jd wrote:
Not being one to brag, but I've managed 0.5% + 1.1%/voice at 24 kHz with variable volume, pitch and looping with ~2K of IWRAM usage.

OK, now I need help. If it's possible to make a mixer twice as fast as mine, then what am I doing wrong in the assembly language code generated by compiling gbmxr.c in GCC? Or is that a "tell you but then I'd have to kill you" trade secret?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#2345 - jd - Sun Feb 02, 2003 7:10 am

tepples wrote:

OK, now I need help. If it's possible to make a mixer twice as fast as mine,


Actually, it's about 2.5 times as fast as the figures I gave were for 24 kHz, not 18. :)

tepples wrote:

then what am I doing wrong in the assembly language code generated by compiling gbmxr.c in GCC? Or is that a "tell you but then I'd have to kill you" trade secret?


Well, it's not quite that bad, but the code is for a commercial project. Sorry to be a tease, but I don't think it would be wise to reveal how it's done - at least not yet.

#2359 - FluBBa - Sun Feb 02, 2003 12:18 pm

I could probably think of one thing at least.
Don't write to memory more then you need.
If you build a modplayer/mixer for a specific number of channels (say 8) you can probably mix a sample from all channels into a register then write it to memory, instead of writing/adding one sample at a time to memory.
That's how I would have done it.

/FluBBa

#2360 - Splam - Sun Feb 02, 2003 12:34 pm

Yeah, thats how I do it, you can manage about 4 channels at a time without running out of registers, so if you want an 8 channel stereo mixer just do 2 lots 1 for each side. Also some self modifying code comes in handy ;)

#2368 - tepples - Sun Feb 02, 2003 4:07 pm

Splam wrote:
you can manage about 4 channels at a time without running out of registers

How would that work? I can only see how two voices could be mixed in one pass.

r0 mix bus
r1 address of start of wave
r2 offset into wave (fixed-point)
r3 pitch
r4 volume
r5 address of end of wave
r6-r10 (same as r1-r5 for the other voice)
r11-14 temporary values
r15 program counter

What am I allocating registers to that I shouldn't?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#2376 - DekuTree64 - Sun Feb 02, 2003 7:05 pm

col wrote:
However its easier to mix unsigned 8bit samples, so convert them right at the end of the process using your 'volumetable'


Just curious, but wouldn't unsigned samples sound completely different than signed when added together? I think I could speed up my mixer quite a bit if I didn't have to worry about signs, but it just doesn't seem like it would work.

#2379 - col - Sun Feb 02, 2003 7:29 pm

jd wrote:

Not being one to brag, but I've managed 0.5% + 1.1%/voice at 24 kHz with variable volume, pitch and looping with ~2K of IWRAM usage. As you can probably tell, I'm pretty chuffed. :)


damn, i'm only getting 0.6% + 1.3%/voice in mono @ 18k :-/

Do you have the number of channels fixed or variable?

And what are your specs for stereo(panned mono) channels? as thats what most good games seem to use.

cheers

col.

#2387 - jd - Sun Feb 02, 2003 9:05 pm

col wrote:

Do you have the number of channels fixed or variable?


The maximum is 8, but it skips unused channels very efficiently. As a result of this on average a complex protracker MOD only uses 4.5% CPU at 24 kHz.

col wrote:

And what are your specs for stereo(panned mono) channels? as thats what most good games seem to use.


I assume by panned mono you mean each channel has a left volume and right volume? I haven't implemented this because most people don't use headphones. However, I'd estimate it would slow it down by about 25% at the most - i.e. 0.5% + 1.4%/voice at 24 kHz. But even with this small cost I don't think it's worth it unless you've got CPU cycles to spare.

#2398 - col - Mon Feb 03, 2003 1:36 am

jd wrote:

I assume by panned mono you mean each channel has a left volume and right volume? I haven't implemented this because most people don't use headphones. However, I'd estimate it would slow it down by about 25% at the most - i.e. 0.5% + 1.4%/voice at 24 kHz. But even with this small cost I don't think it's worth it unless you've got CPU cycles to spare.


Hmm, this is interesting :)

Firstly, how do you know most people don't use headphones?

2nd, If folk don't use headphones, why have you chosed such a high sample rate? IMO no-one using the gba speaker is going to notice the difference between 18k and 24k(even if interpolation is being used)

3rd if you're going to pick a high sample rate, why such an odd one?
24khz dosn't fit well with a vblank approach to buffer switching, and will cause occasional clicks. If you're using a 'two timers' approach, why not go for 16k or 32k to sync with the hardware's re-sampling rate - this should give a cleaner sound

If you can do stereo for only an extra 25%, why not drop the bit rate by 25% to 18k - and give the (supposed few) headphone users a treat, no-one else will tell the difference, and the code will go at the same speed...

cheers

col.

#2400 - col - Mon Feb 03, 2003 1:42 am

DekuTree64 wrote:

Just curious, but wouldn't unsigned samples sound completely different than signed when added together? I think I could speed up my mixer quite a bit if I didn't have to worry about signs, but it just doesn't seem like it would work.


The sample data needs to be converted to 8bit unsigned before you use it.
Then when you add and multiply the unsigned samples, you must add a bias value to keep zero at zero - in practice this can be got for free depending on your algorithm (ARM asm has a multiply accumulate instruction that gives you a free addition as part of a multiplication instruction.)

cheers

col.

#2403 - jd - Mon Feb 03, 2003 3:08 am

col wrote:

Firstly, how do you know most people don't use headphones?


I think it was mentioned as one of the reasons given by Nintendo for the GBA SP not having a headphone socket. However, I've just done a search and I can't for the life of me find the page where I read that. :/

col wrote:

2nd, If folk don't use headphones, why have you chosed such a high sample rate? IMO no-one using the gba speaker is going to notice the difference between 18k and 24k(even if interpolation is being used)


Three reasons:

1) My mixer gets more efficient at higher mixing rates.
2) The difference is noticeable through the speakers. (18 kHz only allows a maximum frequency of 9 kHz, which means aliasing is common.)
3) The difference is *very* noticeable through headphones. I'd much rather spend the CPU time on a higher mixing rate than on panning as (to my ears) it makes a much bigger difference to percieved quality.

col wrote:

3rd if you're going to pick a high sample rate, why such an odd one?
24khz dosn't fit well with a vblank approach to buffer switching, and will cause occasional clicks. If you're using a 'two timers' approach, why not go for 16k or 32k to sync with the hardware's re-sampling rate - this should give a cleaner sound


I chose 24 kHz since it gives the best compromise between CPU usage and quality in my opinion. I didn't feel the extra quality offered by 32 kHz jusitified the extra CPU usage. I should also point out that I'm actually using (approximately :) 24001.739628 Hz so as to fit exactly with the GBA's timers. As for hardware resampling, that doesn't seem to be major problem - it certainly sounds better at ~24 kHz than ~22.05, ~20 or 16.384 (which are the others I've tried).

#2410 - DekuTree64 - Mon Feb 03, 2003 7:52 am

[quote="colThe sample data needs to be converted to 8bit unsigned before you use it.
Then when you add and multiply the unsigned samples, you must add a bias value to keep zero at zero[/quote]

So, like you'd add a sample to your mix buffer, and then subtract 128 so it's basically the same thing? Not sure if I could really make any improvements with that. I was thinking about adding samples together 2 at a time (into a 16-bit mix buf), which is actually what I already do, but currently I have to load a word, separate it into 2 signed halfwords, add the samples, and put them back together. Not sure if it would be faster to just use ldrsh/strh, since it's in IWRAM, but it does let me use ldm/stm to work on a lot of samples at once.

#2423 - col - Mon Feb 03, 2003 7:13 pm

jd wrote:

I think it was mentioned as one of the reasons given by Nintendo for the GBA SP not having a headphone socket...


:) yeah, they had to choose between:

"Nobody uses headphones anyway"
and
"The decision was made to use a non-standard headphone socket in order to milk as much money as possible out of our customers"


jd wrote:

Three reasons:
1) My mixer gets more efficient at higher mixing rates.
2) The difference is noticeable through the speakers. (18 kHz only allows a maximum frequency of 9 kHz, which means aliasing is common.)
3) The difference is *very* noticeable through headphones. I'd much rather spend the CPU time on a higher mixing rate than on panning as (to my ears) it makes a much bigger difference to percieved quality.


1) intriguing
2) as soon as you start changing pitch in a simple mixer, you start haemorraging aliasing noise anyway - unless of course you have incorporated band-limited interpolation into your re-sampling algorithm? ;-)
I did some tests a while back using soundforge - monitoring on some high quality nearfields, and my conclusion was that (in 8bit), there is a significant difference between 16 and 18k, but above 18k the returns start diminishing dramatically.
(Did you re-sample all your sounds for each bit-rate in your tests? - this will make quite a difference - if your sounds have been prepared for 24k and you start using them in 16k, there will be bigger pitch shifting jumps, and this will hurt the quality far more than anything else.)
3) c'mon - everyone knows that nobody uses headphones anyway ;p
but seriously, a good stereo soundstage can dramatically effect perception of graphic quality and the feeling of immersion that the gamer gets from the game - don't underestimate.

Whatever, you have some nice spect for your mixer, though I'd still like to hear tested specs/iwram usage for 18k stereo(panned mono) channels :) - its much easier to run out of registers that way...


cheers


cheers

col

#2446 - jd - Tue Feb 04, 2003 3:17 am

col wrote:

:) yeah, they had to choose between:

"Nobody uses headphones anyway"
and
"The decision was made to use a non-standard headphone socket in order to milk as much money as possible out of our customers"


LOL. :)

Mind you, the SP isn't exactly going to increase headphone use. :/

col wrote:

1) intriguing


It is, isn't it? :)

col wrote:

2) as soon as you start changing pitch in a simple mixer, you start haemorraging aliasing noise anyway - unless of course you have incorporated band-limited interpolation into your re-sampling algorithm? ;-)


I see what you mean, but the effect is going to be much worse when the rate you're playing the sample at is closer to the mixing rate so boosting that is still beneficial. Also, once you try to play a sample at above the mixing rate things can get *really* nasty, and that's less likely to happen with a higher mixing rate.

col wrote:

I did some tests a while back using soundforge - monitoring on some high quality nearfields, and my conclusion was that (in 8bit), there is a significant difference between 16 and 18k, but above 18k the returns start diminishing dramatically.


I did some tests with MODplug Tracker before settling on 24 kHz. In my test, I found each of the following transistions gave a similar perceived improvement in sound quality:

16->20 kHz
20->22 kHz
22->24 kHz
24->32 kHz

I guess it depends on the music you're using though.

col wrote:

(Did you re-sample all your sounds for each bit-rate in your tests? - this will make quite a difference - if your sounds have been prepared for 24k and you start using them in 16k, there will be bigger pitch shifting jumps, and this will hurt the quality far more than anything else.)


No. Pretty much every sound in the game can be played at any frequency so there wouldn't be a lot of benefit in doing so.

col wrote:

3) c'mon - everyone knows that nobody uses headphones anyway ;p
but seriously, a good stereo soundstage can dramatically effect perception of graphic quality and the feeling of immersion that the gamer gets from the game - don't underestimate.


I know what you mean, but I still think I'd rather have the extra sound quality. I may yet change my mind though - I'm decisive like that. :)

col wrote:

Whatever, you have some nice spect for your mixer, though I'd still like to hear tested specs/iwram usage for 18k stereo(panned mono) channels :) - its much easier to run out of registers that way...


IWRAM usage should only be ~250 bytes greater (so the total would still be ~2K) since the mixing buffers are in EWRAM. Also, I just made some changes to my code so I've currently got a register free and there are another three registers I could free without too much pain so I wouldn't expect that to be a significant problem.

#2485 - col - Tue Feb 04, 2003 8:53 pm

jd wrote:

I see what you mean, but the effect is going to be much worse when the rate you're playing the sample at is closer to the mixing rate so boosting that is still beneficial. Also, once you try to play a sample at above the mixing rate things can get *really* nasty, and that's less likely to happen with a higher mixing rate.


Why will the aliasing be worse as the sample you're playing gets closer to the mixing rate?
surely as you get closer, the frequency of the noise will drop to the the extent that it will become less! noticable (especially on the gba speaker).
Anyhow, when would you ever need to play a sample with its fundemental frequency set to near 18k? It's really only harmonics we have to worry about, and in that case, you will get (very)audible aliasing no matter what your mixing frequency is unless you use high quality interpolation to re-sample as you pitch the sounds!!

jd wrote:

I did some tests with MODplug Tracker before settling on 24 kHz. In my test, I found each of the following transistions gave a similar perceived improvement in sound quality:

16->20 kHz
20->22 kHz
22->24 kHz
24->32 kHz

I guess it depends on the music you're using though.

col wrote:

(Did you re-sample all your sounds for each bit-rate in your tests? - this will make quite a difference - if your sounds have been prepared for 24k and you start using them in 16k, there will be bigger pitch shifting jumps, and this will hurt the quality far more than anything else.)


No. Pretty much every sound in the game can be played at any frequency so there wouldn't be a lot of benefit in doing so.


Using a simple non-interpolating mixer, the further you pitch a sound away from the rate it was recorded(re-sampled) at, the worse it will sound!!
If you use a mod for testing that was written for 44.1k then it will obviously sound much worse the lower you go(Thats why there are 'instruments' in a mod, to allow the use of multiple versions of a the same sound - to minimise this problem)
If you re-sample the sounds to fit with the bit-rate you are mixing at, a well constructed mod should sound a whole lot better.

jd wrote:

IWRAM usage should only be ~250 bytes greater (so the total would still be ~2K) since the mixing buffers are in EWRAM. Also, I just made some changes to my code so I've currently got a register free and there are another three registers I could free without too much pain so I wouldn't expect that to be a significant problem.


curiouser and curiouser - this is cheeky but - are your specs from testing on gba hardware, or from cycle counting and calculations? ewram is just so slow, and you have registers to spare !?

cheers

col.

#2537 - jd - Thu Feb 06, 2003 1:24 am

col wrote:

Why will the aliasing be worse as the sample you're playing gets closer to the mixing rate?
surely as you get closer, the frequency of the noise will drop to the the extent that it will become less! noticable (especially on the gba speaker).


If you're playing the sample at 16 kHz then I agree, it will sound better mixed at 16 kHz than at 24 kHz. However, if you aren't playing the sample at the mixing rate (which is a very common situation) then the average error will be much greater with a lower mixing rate that with a larger one. (I agree that when the play rate gets very near the mix rate the quality is better - I don't know what I was smoking when I wrote the opposite of that before. :)

col wrote:

Anyhow, when would you ever need to play a sample with its fundemental frequency set to near 18k?


Quite often!

col wrote:

It's really only harmonics we have to worry about, and in that case, you will get (very)audible aliasing no matter what your mixing frequency is unless you use high quality interpolation to re-sample as you pitch the sounds!!


Unless I've misunderstood, it sounds like you're arguing that increasing the mixing rate doesn't reduce aliasing, which is clearly not the case. (For example, consider the case of an infinite mixing rate - there wouldn't be any aliasing at all. The higher the mixing rate, the less aliasing there is.)

col wrote:

Using a simple non-interpolating mixer, the further you pitch a sound away from the rate it was recorded(re-sampled) at, the worse it will sound!!


Yes, but that's all that can be done on the GBA. An interpolating mixer isn't practical (at least not if you want any CPU time left afterwards :) and there isn't enough storage space to store all the samples at lots of different mixing rates. That's the whole reason for having a pitch-shifting mixer in the first place.

col wrote:

If you use a mod for testing that was written for 44.1k then it will obviously sound much worse the lower you go(Thats why there are 'instruments' in a mod, to allow the use of multiple versions of a the same sound - to minimise this problem)


I've got a collection of thousands of MODs, and I've never seen one that had more than one copy of the same instrument to improve its quality when it was played at different pitches. The different instruments are just that - drums, pianos, trumpets, etc.

Also, the Amiga doesn't have a "mixing rate" per se, so it isn't really worthwhile to optimise songs in the way you describe. Besides, the ones I'm using sound just fine when mixed at 24 kHz, but very poor at 16 kHz.

col wrote:

If you re-sample the sounds to fit with the bit-rate you are mixing at, a well constructed mod should sound a whole lot better.


That only works if you know what pitch the samples will be played at - and if you know that then you've got no need for a mixer that's capable of pitch-shifting in the first place.

col wrote:

curiouser and curiouser - this is cheeky but - are your specs from testing on gba hardware, or from cycle counting and calculations?


Testing on hardware.

col wrote:

ewram is just so slow, and you have registers to spare !?


I'm only writing to EWRAM twice (for Direct Sound A and B), not reading and writing for every channel like your mixer does. Putting the mixing buffer in IWRAM would only speed up my routine by ~5% so it's not really worth it.

#2558 - FluBBa - Thu Feb 06, 2003 11:00 am

jd wrote:

I'm only writing to EWRAM twice (for Direct Sound A and B), not reading and writing for every channel like your mixer does. Putting the mixing buffer in IWRAM would only speed up my routine by ~5% so it's not really worth it.


Why are you using both Direct Sound A & B?
Is that because of speed reasons?
_________________
I probably suck, my not is a programmer.

#2581 - jd - Fri Feb 07, 2003 8:14 pm

FluBBa wrote:
Why are you using both Direct Sound A & B?
Is that because of speed reasons?


No, it would actually be marginally faster to mix all 8 channels at once. However, doing it as 2 batches of 4 channels does have a couple of advantages:

1) Better quality. The more channels you mix together, the less accuracy you get.

2) Less IWRAM usage. Having a shorter 4 channel mixer and calling it twice uses less IWRAM than having a longer 8 channel mixer and calling it once.

#3327 - NEiM0D - Sat Feb 22, 2003 9:31 pm

How can you mix 4 channels per time?
I've managed to do a 3 channel mix very fast.
but I didn't have enough registers for 4 channels.

#3328 - NEiM0D - Sat Feb 22, 2003 9:32 pm

And with 2K IWRAM usage you mean the mixer code plus buffers or something else?

#3364 - jd - Sun Feb 23, 2003 5:22 pm

NEiM0D wrote:
How can you mix 4 channels per time? I've managed to do a 3 channel mix very fast. but I didn't have enough registers for 4 channels.


Sorry, it's for a commercial project so I can't go into details.

NEiM0D wrote:
And with 2K IWRAM usage you mean the mixer code plus buffers or something else?


Mixer code. The buffers are in EWRAM.