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 > Audio mixer

#35923 - gbawiz - Sun Feb 13, 2005 12:38 am

Hello,
I have a question about the interrupt routine of audio mixers.

Do the swapping of buffers and the mixing routine have to be done inside the VBLANK interrupt?

My audio mixing program is running too slow and I cannot find the reason why.

#35924 - tepples - Sun Feb 13, 2005 1:05 am

In a vblank-synchronized mixer, the buffer swap has to happen immediately after vblank, but mixing can happen anytime.

However, if your mixer is taking longer than vblank, it's probably taking too long. Have you compiled it as ARM code with -O3 and put it in IWRAM?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#35949 - gbawiz - Sun Feb 13, 2005 3:01 pm

tepples wrote:
In a vblank-synchronized mixer, the buffer swap has to happen immediately after vblank, but mixing can happen anytime.

However, if your mixer is taking longer than vblank, it's probably taking too long. Have you compiled it as ARM code with -O3 and put it in IWRAM?


Hello,
Thanks tepples,

My mixer routine is in assembly and is stored in IWRAM which seemed to speed the mixer up a little bit. Im not sure about the -O3 option, does this only work when compiling the C source?

I have a few questions:

1.) Can a four channel mixer be written in C source and work perfectly or does it have to be written in assembly?

2.)Do the mixing routines need to be stored in IWRAM in order for them to work?

3.)can the compiler affect how fast the code will run?

I have been trying to get my mixer routine working for some time now and without success.

I would be grateful for any advice
Many thanks

#35955 - tepples - Sun Feb 13, 2005 4:54 pm

gbawiz wrote:
My mixer routine is in assembly and is stored in IWRAM which seemed to speed the mixer up a little bit.

You were one step ahead of me.

Quote:
Im not sure about the -O3 option, does this only work when compiling the C source?

Yes.

Quote:
1.) Can a four channel mixer be written in C source and work perfectly or does it have to be written in assembly?

The mixer from TOD is in C, and it works fine with multiple channels.

Quote:
2.)Do the mixing routines need to be stored in IWRAM in order for them to work?

In order for them to work in real time with a decent number of channels at a decent sample rate, you need them to be in zero wait state RAM, and this is IWRAM.

Quote:
3.)can the compiler affect how fast the code will run?

Yes. ARM's expensive compiler (if you have to ask, you can't afford it) is rumored to generate faster code than GCC can.

Quote:
I have been trying to get my mixer routine working for some time now and without success.

Working, or working in real time? If you just want working, to where you'll make optimizations later, try making a reference implementation in C using the Allegro library.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#35997 - gbawiz - Sun Feb 13, 2005 11:14 pm

Quote:
The mixer from TOD is in C, and it works fine with multiple channels.


Thanks,
I have looked at the file gbmxr.c and have tried to implement it into my program for testing.
One thing Im not sure is about the frequency to play at.
i.e I have a sample at 8192hz
Code:
gbmxr_voices[0].sample_rate=8192

makes the sample sound awful and really high pitched with noise.

What number should I try to make the sample sound correct?
Thanks again

#36001 - tepples - Sun Feb 13, 2005 11:47 pm

gbawiz wrote:
I have looked at the file gbmxr.c and have tried to implement it into my program for testing.
One thing Im not sure is about the frequency to play at.
i.e I have a sample at 8192hz
Code:
gbmxr_voices[0].sample_rate=8192

makes the sample sound awful and really high pitched with noise.

What number should I try to make the sample sound correct?
Thanks again

It uses 16.16 fixed-point sample rates relative to the mixing rate. For example, use the real sample rate * 65536 / 18157 Hz.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#36388 - gbawiz - Fri Feb 18, 2005 5:19 pm

Hello,
I have completed my audio mixer and it works fine when I program using 'C' code and install object into IWRAM.
One thing which I could not understand is that ASM was supposed to be faster than 'C' yet it turned out to be way too slow when I programmed my stepsample routine in ASM.
I Must have left something out.

Someone mentioned 'wait states'
are these something which I would have to learn to create when programming in ASM or are these created by the compiler

Thanks

#36392 - poslundc - Fri Feb 18, 2005 6:18 pm

gbawiz wrote:
Hello,
I have completed my audio mixer and it works fine when I program using 'C' code and install object into IWRAM.
One thing which I could not understand is that ASM was supposed to be faster than 'C' yet it turned out to be way too slow when I programmed my stepsample routine in ASM.
I Must have left something out.


Assembly is neither inherently faster or slower than C. The job of the C compiler is to translate your C code into the most optimal assembly code that it can. Try running GCC with the -S switch and see the intermediary assembly code it generates off of your C code.

The idea behind programming in assembly directly is that if you are smarter than the compiler, you can generate better code than it can.

Quote:
Someone mentioned 'wait states'
are these something which I would have to learn to create when programming in ASM or are these created by the compiler


Wait states are the number of cycles it takes to perform a read or write to memory. Each area of memory on the GBA has its own waitstates. IWRAM has a waitstate of 0, which means a read or write to memory takes only a single cycle. This makes it a very good place to run code out of or put data that you will have to rigorously access, but you only have 32K of it.

EWRAM and cartridge ROM both take much longer to read data out of. (There are a number of factors that determine whether EWRAM or ROM is the faster of the two, but generally ROM is faster for sequential access and EWRAM is faster for random access.) So if you have a bunch of LDRs in your assembly code pointing to random areas of ROM, it might wind up being much slower than the assembly code generated by your C compiler.

Dan.