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 > Apex Audio System

#9781 - jd - Mon Aug 18, 2003 1:15 am

I finally finished putting together the first version of the Apex Audio System (AAS) which is based on the routines that were developed for Payback.

It supports up to 8 channels and takes an average of just 2.8% CPU to play a 4 channel MOD at 16 KHz. It's free for non-commercial use and can be downloaded from the link below:

http://www.apex-designs.net/tools_aas.html

Feedback welcome!

#9792 - Sweex - Mon Aug 18, 2003 9:21 am

It does not support playback of sound effects, does it? Because that's what all module players (except krawall) miss imho!:-(

Module players are fine for any demo, but when you do a game you need to have some way of playing sound effects.

Any chance that there will be support for playing sound effects in the near future?
_________________
If everything fails, read the manual: If even that fails, post on forum!

#9799 - col - Mon Aug 18, 2003 1:11 pm

Hi James,

Have you implemented stereo (panned mono) channels yet?
We thinking about licencing a sound engine on our project, but stereo is a must, as is sound effect playback.

cheers

Col

#9801 - jd - Mon Aug 18, 2003 2:24 pm

Sweex wrote:

Any chance that there will be support for playing sound effects in the near future?


It already supports sound effects.

#9802 - FluBBa - Mon Aug 18, 2003 2:24 pm

Maybe people should start by reading the docs?
Just a thought.
_________________
I probably suck, my not is a programmer.

#9803 - jd - Mon Aug 18, 2003 2:26 pm

col wrote:

Have you implemented stereo (panned mono) channels yet?
We thinking about licencing a sound engine on our project, but stereo is a must, as is sound effect playback.


At the moment it only supports "hard" stereo (sounds come out of left or right speakers, so you need to use two channels if you want them to come out both) or mono. It does support sound effect playback at the same time as MOD playback. (Perhaps I need to amend the docs to make this clearer?)

#9864 - jd - Wed Aug 20, 2003 2:42 pm

Just a quick note to let you guys know that I've released a minor update to AAS. The header files have been improved to make them easier to use from C++ and the docs have been amended to include a more complete list of the resources used by AAS in the "Getting Started" section. The updated version can be downloaded here:

http://www.apex-designs.net/tools_aas.html

As always, feel free to email me at james.daniels@apex-designs.net with any comments/problems/ideas etc.

#9887 - NEiM0D - Thu Aug 21, 2003 6:51 am

Hi James,
I've been doing some disassembling, and I noticed you used the stack register in the mixing process;

r4 = byte from sample;
r5 = byte from sample;
lr = byte from sample;

r6 = r4 + lr <<16;
lr = byte from sample;
r7 = r5 + lr <<16;

etc, and one time: sp = r4 + lr <<16;

This might cause problems when an interrupt occurs and the mixing process currently crushed the sp.

When an interrupt occurs, BIOS automaticly pops {r0-r3,r12,lr} to the stack (but the stack pointer is currently crushed by the mixing routine).
Ofcourse, you can disable multiple interrupts when your mixing process is busy, but is that really safe?

Also, I see you bragging alot about how fast your mixer is, but to tell you the truth, you can't compare this to other mixers.
Simply because yours doesn't use a temporary buffer which decreases the speed alot.

#9888 - Dev - Thu Aug 21, 2003 7:55 am

Provided that:

1. Timings are done on actual hardware and not an emulator
2. Only the sound code is changed in the test program
3. The same playback rate is used
4. The same .MOD is used for testing (duh)
5. The same effects used by the .MOD are supported/unsupported by both mixers.

Then, and only then, will the relative comparisons be valid.

Timings done on an emulator (at least those publicly available) are completely bogus and not to be trusted.

Dev.

#9891 - FluBBa - Thu Aug 21, 2003 8:38 am

NEiM0D wrote:

Also, I see you bragging alot about how fast your mixer is, but to tell you the truth, you can't compare this to other mixers.
Simply because yours doesn't use a temporary buffer which decreases the speed alot.

Why is it necessary to use a temporary buffer to compare mod players/sound mixers? just so you can display some flashy osciloscopes?
Oooor I might just have missed some very important thing about it alltogether.
_________________
I probably suck, my not is a programmer.

#9896 - jd - Thu Aug 21, 2003 12:31 pm

NEiM0D wrote:

When an interrupt occurs, BIOS automaticly pops {r0-r3,r12,lr} to the stack (but the stack pointer is currently crushed by the mixing routine).


There's a different sp that's used when an interrupt ocurs so corrupting sp in the mixer is safe with Fast and Single Interrupts, but you're right that there may be a problem with Multiple Interrupts. I'll get it fixed ASAP.

NEiM0D wrote:

Also, I see you bragging alot about how fast your mixer is, but to tell you the truth, you can't compare this to other mixers.
Simply because yours doesn't use a temporary buffer which decreases the speed alot.


So it's not valid to compare because it works in a much more efficient way? That seems like a rather arbitary restriction.


Last edited by jd on Fri Aug 22, 2003 1:32 am; edited 1 time in total

#9910 - jd - Thu Aug 21, 2003 5:17 pm

jd wrote:

There's a different sp that's used when an interrupt ocurs so corrupting sp in the mixer is safe with Fast and Single Interrupts, but you're right that there may be a problem with Multiple Interrupts. I'll get it fixed ASAP.


This issue has now been resolved - thanks NEiM0D! The updated code can be downloaded here:

http://www.apex-designs.net/tools_aas.html

I've also created an AAS discussion list.

#9947 - NEiM0D - Fri Aug 22, 2003 7:01 pm

Hi James,

jd wrote:

This issue has now been resolved - thanks NEiM0D!


np.
jd wrote:

So it's not valid to compare because it works in a much more efficient way? That seems like a rather arbitary restriction.


Mostly because if other mixers had no temporary buffer, they might even be faster than your mixer =)

#9951 - tepples - Fri Aug 22, 2003 7:46 pm

Mixers with no temporary buffer have a hard time reproducing rich orchestration. They tend to need chord samples rather than placing the notes of a chord in separate channels, which eats more ROM space.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#9953 - jd - Fri Aug 22, 2003 8:08 pm

NEiM0D wrote:

Mostly because if other mixers had no temporary buffer, they might even be faster than your mixer =)


Yes, but they might not. :)

My understanding is that other mixers use a temporary buffer because conventional wisdom says that's the fastest way to get more than 4 channels. With AAS, we've found a way to get 8 channels without needing a temporary buffer. Surely, that means AAS is the fastest mixer up to 8 channels. Beyond that I'll admit that other mixers are better because AAS simply doesn't support that number of channels (yet :).

#9954 - jd - Fri Aug 22, 2003 8:15 pm

tepples wrote:
Mixers with no temporary buffer have a hard time reproducing rich orchestration. They tend to need chord samples rather than placing the notes of a chord in separate channels, which eats more ROM space.


This has nothing to do with whether they use a temporary buffer or not. Instead, it is the number of channels that causes these problems, and AAS proves this is not a fundamental limitation of mixers without temporary buffers. (In fact, I believe that Engine's mixer is also one-pass (i.e. does not use temporary buffers).)

Having said that, AAS currently only supports 4 channel Protracker MODs so your observation is still valid for the time being - although I'd disagree that tunes with a small number of channels are usually bigger than those with a large number. Also, having more channels uses more CPU power, so it's really a question of what a specific project needs.