Audio Mixer v3.1 released (including C integration)

[roondar]

After seeing my audio mixer being used in several productions, I decided to revisit it and turn it from a simple example into a more complete project, with multiple examples, new features, reworked code, the ability to use it in C programs and full documentation.

The result is my new mixer, version 3.1. I'm quite happy with the new features

Here's a quick overview of the mixer and it's new features:
Features:

• Up to four samples can be mixed onto a single hardware channel.
• High performance: mixing four samples onto a single channel at 11KHz takes only 3.7% CPU time on a 7MHz 68000 without Fast RAM*.
• Can be run while a music playback routine is running, as long as the music routine does not access the hardware channel(s) used by the Audio Mixer.
• Up to four hardware channels can be assigned to the Audio Mixer, allowing up to 16 samples being played back at the same time.
• Sample playback is priority based, so that drowning out of important effects can be prevented.
• Samples can be stored anywhere in RAM, including in Fast RAM and Slow RAM.
• Samples can be set to loop and both looping/non-looping samples can be stopped on request
• Samples can be assigned to one of the virtual channels the mixer uses (up to 4 per hardware channel), allowing fine-grained control of SFX playback.
• Supports playback of samples of any size that will fit in RAM**.
• Samples no longer need to be a multiple of the mixer buffer in size, but rather just a multiple of 4 bytes in size
• Sample rate used can be configured at assembly time, using standard Paula period values.
• Fully PC relative code is used to make relocation as easy as possible.
• Configuration now via a separate configuration file, which requires only a period value to set other values automatically (no more calculating the buffer size manually)

*) this number is slightly higher than the previous version, but part of that is due to an improved method for measuring performance. The old mixer uses 3.4% CPU time with the new performance measuring method.
**) in practice, this is limited by the largest maximum single block of free RAM that exists. A system with multiple memory expansions will be limited to a much smaller maximum sample size than the total RAM size would seem to indicate.


You can find the new mixer and it's full documentation here:
https://powerprograms.nl/projects/audio_mixer.html


I'm particularly happy the mixer now supports samples looping and samples that aren't multiples of the entire mixer buffer in size.

Hope it's useful for you guys

Edit: version 3.2 has been released. It fixes a bug in the way I set up the XREF directives (this cause errors on several assemblers, notably vasm 1.9d)

[ross]

Thanks roondar!

I bookmarked the link

[roondar]

Originally Posted by ross

Thanks roondar!

I bookmarked the link

No problem, hope you find it useful!

---
One thing I forgot to make clear in my original post is that the mixer configuration does let you pick from several optimisation options (exchanging some flexibility/RAM use for some peformance). The 3.7% CPU time figure is without taking those options into account.

If you use those options, the mixer performance can get very similar to the old version (3.3% CPU time on A500 with 11KHz x4 samples), but also has the same requirement as the old mixer regarding the sample length needing to be a multiple of the per-frame mixer buffer size. I chose not to use those optimisations for the named figure because I personally find the added flexibility of 4 byte-multiple samples to be worth more than the extra CPU time.

But for those who'd rather have the extra speed, the option is there

[skyzoo73]

Fantastic Roondar, going from 4 channels to 16 channels seems like a miracle for the Amiga.
Congratulations.Can't wait for it to spread to future games.
I dream that such a routine will also be integrated into the Scorpion Engine someday.

And of course a tracker and tools to create music with it.

p.s. will it be possible to mix music and sounds within a multiplexed channel?
For example in a configuration

3 real channels (music) +
2 multiplex channels (music) +
2 multiplex channels sounds ?

[no9]

Thanks @roondar! I was waiting for this and try to break something there...

Originally Posted by skyzoo73

And of course a tracker and tools to create music with it.

p.s. will it be possible to mix music and sounds within a multiplexed channel?

Why woudn't it be? Everything is a sound. Taking into account some limitations and side effects it should work. I have an idea to exploit an existing tracker format.

[roondar]

Originally Posted by skyzoo73

Fantastic Roondar, going from 4 channels to 16 channels seems like a miracle for the Amiga.
Congratulations.Can't wait for it to spread to future games.

Careful, nothing is free
At 16 channels the mixer uses over 15% CPU time on an A500. So this is probably something better suited for A1200 level computers.
(and of course, using all 4 hardware channels for mixer playback means existing music players will definitely not be able to play back any music)

I dream that such a routine will also be integrated into the Scorpion Engine someday.

That would be interesting. I don't know what would be needed for Scorpion integration. Theoretically I think it should be possible, but if it's practical? No idea

And of course a tracker and tools to create music with it.

There are some limits that might make that difficult (see also my answer below to no9)

p.s. will it be possible to mix music and sounds within a multiplexed channel?
For example in a configuration

3 real channels (music) +
2 multiplex channels (music) +
2 multiplex channels sounds ?

It kind of depends how you intend to do this. The mixer does not support mixing a pro-tracker player and mixer playback onto the same channel, but if you can somehow fire samples to the mixer at the right time you might be able to do something like that (see also my answer to no9)


---

Originally Posted by no9

Thanks @roondar! I was waiting for this and try to break something there...

No problem, happy breaking

Why woudn't it be? Everything is a sound. Taking into account some limitations and side effects it should work. I have an idea to exploit an existing tracker format.

Technically you're of course 100% correct.

That said, there's a couple of issues that you'd need to take into account, though:

• The mixer uses only one sample frequency/period value, so if you need multiple pitches or pitch slides, separate samples containing this must be provided for each pitch/slide.
• While the new mixer does allow setting of the HW channel volume used, this applies to all samples played back onto the channel so any volume changes that need to be independent of SFX will also need separate samples containing those changes.
• The mixer provides only limited control over when samples play - there's a variable latency depending on when the sample is requested. This will vary from "sample starts playing effectively immediately" to "it takes a full frame before the sample starts playing". This not only makes timing tracker music + mixer music accurately harder, it also makes some "effects" from trackers really hard to copy - except by making a sample that already contains them.

If you can work within these limitations, it can be done. But I don't know what the effect of the variable timing will be. 20ms variability in timing might be enough to make the music sound 'off', I dunno really.

That said, I'd be interested to see what you come up with

[pandy71]

Technically with such low sample rates simple sample interleaving can double number of channels - one channel in lower byte and second channel in upper byte of same DMA word, samples need to be same length and sampled at half but null stuffing (replacing non existent samples by 0) can be used to partially overcome this requirement. Of course Paula channel sample rate must be twice rate of samples.
bonus is that they can be 8 bit so no loss of SNR.

I didn't analyzed your code roondar so appolgies if this is method used by you.

[alexh]

Thanks for all the hard work.

[roondar]

Originally Posted by pandy71

Technically with such low sample rates simple sample interleaving can double number of channels - one channel in lower byte and second channel in upper byte of same DMA word, samples need to be same length and sampled at half but null stuffing (replacing non existent samples by 0) can be used to partially overcome this requirement. Of course Paula channel sample rate must be twice rate of samples.
bonus is that they can be 8 bit so no loss of SNR.

I didn't analyzed your code roondar so appolgies if this is method used by you.

I'm not using sample interleaving, no. I've always understood that this causes a rather annoying and audible side-effect of a 'whine' of some sort, so I've used sample addition instead.

Originally Posted by alexh

Thanks for all the hard work.

No problem, hope it's useful

[pandy71]

Originally Posted by roondar

I'm not using sample interleaving, no. I've always understood that this causes a rather annoying and audible side-effect of a 'whine' of some sort, so I've used sample addition instead.

Hmmm - do you have recording of this 'whine'?

[roondar]

Originally Posted by pandy71

Hmmm - do you have recording of this 'whine'?

Ah, no sorry - I may not have been very clear. I had looked into the option of interleaving samples back when I made the first version of the mixer. At that time, I found several posts on forums (including EAB if I recall) saying there was a audible whine when going this route. This ultimately was the reason for me to not try it out this way.

AFAIK the given reason for the audible whine was that interleaving on the Amiga could not be done at high enough frequencies to push said 'whine' outside of audible range - but I may be misremembering that.

Hope that's more clear

[pandy71]

Originally Posted by roondar

Ah, no sorry - I may not have been very clear. I had looked into the option of interleaving samples back when I made the first version of the mixer. At that time, I found several posts on forums (including EAB if I recall) saying there was a audible whine when going this route. This ultimately was the reason for me to not try it out this way.

AFAIK the given reason for the audible whine was that interleaving on the Amiga could not be done at high enough frequencies to push said 'whine' outside of audible range - but I may be misremembering that.

Hope that's more clear

Ah OK, seem i misunderstood you - i was curious about whine as in theory it should work fine if proper sample interleaving used (key is to put all samples from one channel in high byte and from another channel in low byte of audio word not mix words). But OK - if it doesn't work then it doesn't work.
THX!

[Karlos]

Sample interleaving would produce a lot of unwanted harmonics if it didn't go through a filter.

Fun fact, the Yamaha DX7 used interleaving for each voice (total DAC frequency is hundreds of kHz) and relies entirely on an analogue filter stage on the output to basically mix the discrete values into a continuous signal.

[NorthWay]

Originally Posted by Karlos

Sample interleaving would produce a lot of unwanted harmonics if it didn't go through a filter.

I once tried playing interleaved samples and there was indeed unwanted stuff, but it kind of went away if I increased the playback frequency.

[pandy71]

Originally Posted by Karlos

Sample interleaving would produce a lot of unwanted harmonics if it didn't go through a filter.

Fun fact, the Yamaha DX7 used interleaving for each voice (total DAC frequency is hundreds of kHz) and relies entirely on an analogue filter stage on the output to basically mix the discrete values into a continuous signal.

In Amiga it going trough few filters so i think with proper sample interleaving it should work - not sure how good 68000 is in byte shuffling.
Sharing/interleaving resources is very common practice - i bet more than 90% of musical synthesizers use resource sharing.
From mathematical perspective this is OK
That's why mentioned by roondar 'whine' triggered my curiosity.

[Karlos]

To properly mix the interleaved samples the filter needs to be defined correctly. In this sense it's not that much different than a typical reconstruction filter.

[roondar]

Originally Posted by pandy71

In Amiga it going trough few filters so i think with proper sample interleaving it should work - not sure how good 68000 is in byte shuffling.

Sadly, it's not very good at doing this fast. If the interleaving must be done a byte at a time as you described earlier, the code might be as much as 3-4x slower than the current form of mixing is.

This is because the current form of mixing simply reads and adds together a bunch of longwords (using movem.l for one of the sources), but such interleaving would need to shift all those bytes into position, which is a slow operation.

[pandy71]

Originally Posted by roondar

Sadly, it's not very good at doing this fast. If the interleaving must be done a byte at a time as you described earlier, the code might be as much as 3-4x slower than the current form of mixing is.

This is because the current form of mixing simply reads and adds together a bunch of longwords (using movem.l for one of the sources), but such interleaving would need to shift all those bytes into position, which is a slow operation.

Yes, this is my impression - on plain 68000 shifts are slow - perhaps blitter and some clever masking could be alternative to CPU.

But OK - lets finish at this moment to not derail completely your thread - and as always roondar - great work! Thx!

[ross]

This type of mixing would pair well with copper audio, that as it is now it accepts 16-bit samples and high frequencies, but definitely it require an high amount of memory by the audio stream.

The trick is (well known ):

       move.w  (stream_1)+,d_data
       move.w  (stream_2)+,-(sp)
       move.b  (sp)+,d_data
       move.w  d_data,(output)+

[Muzza]

Great that you've continue to develop this Roondar. I had bodged in support for looping sounds as well as volume control and custom memory allocations, but it looks like they are all officially supported now + more!
EDIT: Being able to set the channel/mode at run time rather than compile time would be nice, although I appreciate it could have implications on code size.