Fastest 8 channel music playroutine

[paraj]

Originally Posted by zero

I found something really interesting: https://github.com/hoglet67/Music5000/wiki

It's an external wavetable sound card for the BBC Micro. It supports 16 channels, but rather than mixing samples it just does time based multiplexing with a 16x sample rate clock.

It won't sound as good as proper sample mixing, but on the other hand it could be handled by the blitter if you don't need per-channel volume control.

Cool idea. It's too bad that the samples are signed otherwise there'd be an easy way to get some crude volume control by using the shifting capabilities of the blitter (one channel would be 1/2, 1/4, ... volume of the other). Depending on how you do the blits it might still be possible by sacrificing some extra DMA cycles (since x.b ASR 1 == (x.b&$80)|(x.b LSR 1)). EDIT: Nevermind, of course this won't work for shifts > 1...

[zero]

I think it might be a viable way to multiplex sound effects, so you could have say 3 normal channels for music and 1 channel split into two or three virtual ones for sound effects. Then volume isn't an issue usually.

If the sample rate could be 40kHz or more it would be viable to use the channel modulation feature to do volume control.

[zero]

You can exceed the 28kHz limit if you don't use DMA to transfer data to Paula. The hardware reference manual says you can copy data to AUDxDAT with the CPU and an interrupt is available for this purpose.

I wonder if you could instead use the copper. DMA copies one word per scanline, so actually the maximum rate is determined by the horizontal scanning frequency. But that makes me think that if you set the copper up to copy data in the middle of a scanline, you could exceed the speed of DMA.

You would need to copy the samples into the copperlist, probably with the blitter.

[paraj]

Originally Posted by zero

You can exceed the 28kHz limit if you don't use DMA to transfer data to Paula. The hardware reference manual says you can copy data to AUDxDAT with the CPU and an interrupt is available for this purpose.

I wonder if you could instead use the copper. DMA copies one word per scanline, so actually the maximum rate is determined by the horizontal scanning frequency. But that makes me think that if you set the copper up to copy data in the middle of a scanline, you could exceed the speed of DMA.

You would need to copy the samples into the copperlist, probably with the blitter.

I seem to recall having read a thread either here or over at ADA (Amiga Demoscene Archive) that basically said that you can't really expect to go much over DMA speed in terms of increasing sample rate. But I really like the idea of feeding audio via a combination of blitter/copper, even if it turns out to not useful in practice.

Have you tried prototyping how it sounds in practice? I don't really have access to any good test data, but in principle it should be really easy to test.

[zero]

My Amiga isn't set up at the moment, so I have not tried anything. Once I get it going I'll see what I can do.

The official hardware guide suggests that 50kHz is possible if you feed Paula via CPU interrupts.

One other interesting thing about that add-on for the BBC is that the wavetable RAM is very small. 128 bytes with 8 bits per sample, total 2k. For chip music you could maybe just pre-render every note you needed to avoid having to do sample rate conversion on the fly.

Edit: For testing I'd use an oscilloscope. It's really easy to see the actual sample rate by outputting a square wave, and with multiple levels you can easily see how your multiplex is working too.

[TCH]

You mean, if i mix 4 channels together, then i only have 7 kHz/sample?

[zero]

If you do time division multiplexing, yes. The sample rate is the sample rate of the real channel divided by the number of virtual channels.

I think if you used such a channel for sound effects only it could be quite realistic to use it in a game. Say you had one real channel split into 3 virtual channels. 24kHz sample rate so you have 3x 8kHz virtual channels. Use the blitter to build playback buffers every frame. At 50Hz you would need to copy 160 bytes per virtual channel per frame, but it would be a simple blitter copy.

The reason I say use it for sound effects is that then you can resample everything to 8kHz before hand and also set volume there, so there is absolutely no processing done on the fly. Then you have 3 real channels for music and 3 virtual ones for sound effects.

[TCH]

If you use the copper or blitter to copy data during scanlines, then isn't that means that you cannot do graphic effects with them?

[pandy71]

This topic deserve to be read:
http://eab.abime.net/showthread.php?t=65348

[ross]

Originally Posted by pandy71

This topic deserve to be read:
http://eab.abime.net/showthread.php?t=65348

Thanks pandy71 to point out this thread.
It's somehow related to mine:
http://eab.abime.net/showthread.php?t=86284

There is somewhere audiotests from user Nut? (not active on the board for a few months)

[zero]

Wow, Nut says that 176kHz is possible. You could multiplex 22 8kHz channels onto that!

Archive link for the volume control stuff: http://web.archive.org/web/201603180...ebby.org/?p=11

[ross]

Originally Posted by zero

Wow, Nut says that 176kHz is possible. You could multiplex 22 8kHz channels onto that!

Archive link for the volume control stuff: http://web.archive.org/web/201603180...ebby.org/?p=11

mmh, I think that 176KHz is very unrealistic.
Not the 176KHz itself (anyhow remember the PWM: >~55KHz require volume=64..) but the 22*8 thing: You have to construct a line with a sequence of copper write (facing the problem of the lost cycle..) and make volume working.

Bye,

[TCH]

Now, can someone explain this to me? Is it really possible to poke sound registers with copper/blitter during scanlines and still use them for other effects on screen?

[zero]

Sure, you can poke the registers. Looking at the thread ross linked to, it seems that poking the register causes an immediate DAC conversion, but I wonder if that is entirely correct because you poke two 8 bit samples at once and obviously the second one is then delayed by the frequency setting.

Anyway, you need to create a copperlist that pokes a value at regular intervals. The interval for 28kHz playback would be around 35.7uS, about twice per scanline. The copper can go a lot faster than that.

The problem will come when you try to do other copper effects. You would have to interlace them with the sound pokes. It's possible but you will either end up wasting a lot of DMA cycles on copper NOPs or making it tricky to blit your sound data into unevenly spaced words.

You could either use the CPU to set up the screen after every vblank and use the copper just for audio, and maybe simulate copper effects with CPU interrupts. But if you want to do a lot of copper stuff it is going to be really tricky.

3:1 at 9kHz per channel is possible with normal DMA playback. If you want to use it in a game, I'd go for 3:1 virtual channels for sound effects and 3 real channels for music. Overhead will be fairly low.

[ross]

Originally Posted by zero

I wonder if that is entirely correct because you poke two 8 bit samples at once and obviously the second one is then delayed by the frequency setting.

Correct. The first byte (upper part of the word written in AUDxDAT) is DAC converted and then the second byte (lower part of the word), after (AUDxPER*281,94)ns (PAL).

So if You want to interleave remember: think in bytes (not word!).
It's possible to interleave with blitter but not so trivial

Originally Posted by zero

Anyway, you need to create a copperlist that pokes a value at regular intervals. The interval for 28kHz playback would be around 35.7uS, about twice per scanline. The copper can go a lot faster than that.
--cut--

A lot of trouble with precise synced video effect and audio rate not line based; the line duration is unfortunately an odd (227) cycle number (not so good for audio copper management...).
For Your needs I think that is better to make something 31250KHz (and submultiples) based.



EDIT: and yes, in this case probably the not-DMA copper/CPU audio does not make sense

[TCH]

@zero:
I don't need 3 channels for sound effects, i need 7 channels for music. Based on what you've said, my guess is that it is not possible on a stock A500, even with the copper doing the mixing.

[zero]

You could do 7 channels on an A500, especially if you only had one volume control per pair of virtual channels (3x 2:1 virtual and a single real channel). It would use a moderate amount of CPU power, but you wouldn't need the copper.

All depends how many CPU cycles you can spare.

[TCH]

But currently there is no such kind of tracker, what can do this, right?

[zero]

No, you would have to write one yourself. Maybe compose on a PC or with AHI soundcard and then write your own playback code. It's not really very complicated.

[TCH]

Unfortunately it's out of my legaue. I'm not that experienced.