A.D.A. Amiga Demoscene Archive

By popular demand (that is, one person complaining that he had no music for his 4k intro) I have decided to release the source code for the music/speech synth used in Planet Loonies. Get it here.

I have written some basic information about how it is used, and the music definition macros should be fairly well documented, but if you have questions of any kind, don't hesitate to ask here.

The code as it stands can obviously be optimized somewhat, since it is written to be compact in my own, special instruction format and not in the normal format.

Enjoy!

@blueberry:

Wasn't Planet Loonies the first and only 4k ever containing speech. Are there pc 4k's with speech?

I think the first 4k to contain speechsynthesis was Void3 by Kolor made in 1999. URL

It's at times like this that you get a feeling of how many people are actually reading ADA. The synth has so far been downloaded from 22 different places in at least 8 different countries. 14 of these downloads came during the first 24 hours. :-D

Add me to the list now :) Thanks for sharing your code! I wish I had the guts to do the same.

I have questions about the audio buffer handling. I remember you mentioned briefly when we met at Solskogen that you didn't need any audio interrupt so I examined this a little.

It seems you don't do any double buffering on the audio buffer and writes samples directly to a "hot" buffer. In your setup, is this a waterproof solution or is it a matter of saving code size and taking the risk of crackling sound here and there?

Your solution depends on writing just a vbl amount of samples, plus one extra (amount of samples is not a integer). According to your tests, does this work 100% in some hardware-strange way or is it another code size saving that will gamble with the sound?

These two questions can't be answered just by listening a bit to the music, I'm curious what thoughts and tests are behind this code.

I currently use both vbl and audio interrupts in my 4k setup, however I use the same vector for both with a switch for type.

Yesterday I made some samples with it and start a mod. Thanks for the nice software Blueberry. :D

since amiga hardware is both fixed and well documented and studied, it is easy to hardcode these samplerate things. for example, you setup 2 buffers with the amount of samples read for some frequency in one frame, program the sound to play at this frequency and then you can use the audio interrupt both to switch the audio buffer pointers, to render the sound into the sound backbuffer and to simulate a vblank interrupt... here is my dirty code for that purpose:

playsample.source

Now your talking my language hehehe...

winden:

You talk (as your source shows) about the usual way of using an audio interrupt which is also documented in the hardware ref. My questions to Blueberry was about his tricky method outside this.

assuming PAL machine.

227 buscycles/line * 312.5 lines/frame = 70937.5 buscycles/frame

The audio HW counters run at half the buscycle frequency.

Blueberry's replay sets audio HW period at 124, which means that 572.0766 samples get played every frame. He mixes 573 samples each frame. Therefore I think the mixing code runs ahead of the audio HW by 0.923 samples every frame.

His mixing buffer is 18*573 samples large, so it will take 18*573/(0.923) = 11174 frames = 223 seconds until the mixing code overtakes audio HW.

Some comments here:

1) the audio HW in a PAL machine can play with a period as low as 114 (that makes the audio HW fetch every 228 buscycles, which still means less than one sample pair fetch per line).

2) In order to keep mixer and audio HW in closer (but not perfect) sync, utilize a 16-bit fraction counter to determine when to mix N and when to mix N+1 samples.

2) Choosing a period of 125 will cause 70937.5/125 = 567.5 samples to be played each frame. That would allow a pure VBL-based mixer to stay in sync with audio hardware, with just an "odd/even" flag, and no other fractional counters. Or mix every 2 frames.


NB: I haven't tested any of the above myself.

Ah ok, didn't look at blueberry code... he is doing a buffer with space for 4*18 vblanks of sound (not 18 seconds, the code gets 4*18*573 samples for the chipmem sound buffer), so that leave the audio dma in automatic loop mode and then just write into a part of the buffer which is not being played.

This method is of course not covered in AHRM since back then burning cpu to realtime calculate the sound was a complete suicide in terms of cpu usage ;)

@winden: the buffer is indeed sized for 4*18 vblanks of sound, but it is divided up into 4 tracks (channels), so each hardware channel will loop after 18 vblanks.

@winden: true, it was enough cpu usage just by starting samples :)

I think this way of doing the sound buffering is interesting both for 4k (size) and to have controlled rastertime usage.

Ah, yes, the audio buffer trick. :)

According to my measurements on both my real Amiga and WinUAE (which thankfully agree on this), a non-interlaced PAL vblank is exactly 227*313 = 71051 audio ticks. Since both 227 and 313 are prime numbers, the only audio periods that will make the sound fit exactly are 227 (15625Hz) and 313 (11332Hz).

In Noxie, I used a period of 227 but had the buffer length incorrectly set to 312 rather than 313, which made the buffer flip round a few seconds before the end of the intro (by which time it plays near silence, so the glitch is not heard).

Planet Loonies uses, as you can see, 124*573 = 71052, which is only one tick different from the vblank length. This can run for more than 20 minutes before it becomes just one vblank delayed. If the sound data is written closely in front of the play position (say, 2 vblanks), the play position is moving slowly _away_ from the write position, so there should be no risk of interference even for long-playing intros, and buffer overrun does not occur until the delay has grown to the whole buffer length, which will take several hours.

According to the AHRM (and to my ears), 124 (not 114) is the shortest period that the hardware can play without distortion. So it is a bit of a lucky strike that a multiple of this number happens to match the vblank length so closely.

One disadvantage of playing 573 samples per vblank is that the number of vblanks spanned by the buffer has to be even, since the number of samples in total has to be even. In my synth, the buffer length must match the echo length, so this puts restrictions on which echo lengths can be chosen, but this is usually not a problem.

blueberry: do you have any idea why the minimum-sample-length is 124 rather than 114? I've always found that restriction very curious...

Kalms: I have found it a bit odd as well. The hardware manual is quite vague on the subject. All it says is:

The figure of 31469 is a theoretical maximum. In order to save buffers, the hardware is designed to handle 28867 samples/second.

I experimented a bit with playing notes with short periods by adjusting the finetune i Protracker. I could clearly hear that when I go below 114 (B-3 with finetune -1) the frequency does not change (though the character of the sound does). This is natural, since it is the maximum rate at which the hardware can fetch samples. Between 124 and 114 the frequency appears to be correct, but there is a slight bit of regular clicking noise, as if it misses a sample once per vblank or something.

I just tried to feed data directly to $dff0aa using the CPU (aud0 dat register). I used a period value of 1 and polled the aud0 interrupt request bits to check if it needed more bytes. Not surprisingly nothing magical happened... Writing without waiting for the samples to play produced a very nice and fuzzy noise though :)

Tested in WinUAE. Maybe not the best platform to check such things.

The result was a bit of an unstable sine wave for low periods. It did get higher and higher frequency as the period went down though.

[offtopic] somewhat related would be to turn off bitplane dma and feed the bitplane data registers directly from the cpu, AHRM says bitplane 0 dataword is fetched last and triggers the display of that pixel strip.

Yeah, then you could do your c2p directly to the screen instead of going through the chipram. :-D

(not)

Tested in WinUAE. Maybe not the best platform to check such things.

I wholeheartedly agree. ;-)

Anyway, as Loaderror (sort of) points out, there is no limit on the sample rate you can achieve if you write the audio data using the cpu, rather than dma (apart from hardware register write bandwidth). Similarly, if you run a resolution like DBLPAL, the scanline rate is twice as high, and thus you get twice as many audio dma slots and hence the maximum sample frequency is twice as high (around 57kHz).

This reminds me of an old data transfer program - Teleport. This was a program to transfer files between two Amigas through a serial cable. It could reach much higher transfer speeds than what you could normally achieve through the serial port (around 900kbit/s IIRC). It did this by turning of all dmas and interrupts (nice, black screen) and then writing (or receiving) the serial data directly with the cpu.

Ah, one of those moments...

I just tried to compile MakeMusic2.s which give me a "user made FAIL" message. I haven't altered anything before assembling it..

Pass 1 ..
** User made FAIL
140 note 32+4+2,a,b,2

Maybe it is some asmone setting. Haven't checked very much yet. Anyone else had this problem?

Removing all chord notes and notes at 0 positions made it compile.

It was a bug in asmpro. wow

I implemented 4X oversampling in my 4k synth the other day. It is just like blurring and downscaling a soundbuffer and improves the cleanlyness of the sound very much. Something for every 4K synth. Put out the tune here if you are interested (no you're not) :

http://myspace.com/rloaderro

@loaderror: I'm no expert but i have the feeling that the last tune (with oversampling) sounds better and somewhat "warmer". And it's a bloody good tune. Wouldn't mind some visuals to go with the tune (in other words: a new 4k from you :o)). Seriously though, i love the sound of your sound engine.

@blueberry:
I've just replicated your results on a clean a1200, displaying a normal LORES non-interlace screen.
The Audio DMA handles periods down to 114 fine. However, there were regular clicks when period was set to 118 or less. At 120 there were no noticeable clicks, but the sound got garbled regularly. I didn't notice any problems at 122. (Perhaps because I didn't wait long enough to hear the errors.)

So yes, the audio hardware in that machine, in that resolution, doesn't like periods less than 124 either.

What I wonder though, is whether or not a machine running DBLPAL really can play sound at higher frequencies than a machine running normal PAL. We know that the audio DMA can fetch quicker, yes, but does the 28867Hz limit still apply for the rest of the audio hardware?

So the conclusion is that >28KHz is not really feasible, but people have been hearing things for the last five or so years? :)

I heard that 14-bit sound might not be possible either because the DACs can only give max 9-bit of precision or so. Can anyone confirm?

I added "Alice Copper" soundtrack and "Du er så sint når du sover" exe music contribution to to myspace page http://myspace.com/rloaderro

New feature this time is fm-synthesis for that raunchy bass line and reggea guitar (ish).

I tried to make a video capture of the 4k (it only works in UAE, not on the real thing.. sigh) yesterday, but I get a horrible framerate. I tried to reduce the screen window to 320x256 and used the Intel Indeo codec. Anyone has experience with capturing from UAE?

I added "Alice Copper" soundtrack and "Du er så sint når du sover" exe music contribution to to myspace page http://myspace.com/rloaderro


Really nice tunes. Can't wait to hear it on decent speakers tonight instead of that awful monitor speakers at work.

As for the winuae recording, i once opened this thread about it on Amigaworld. However, i never got any good results myself. The speed of the pc is probably the deciding factor.

Any chance of spreading the exe for the selected few who don't mind watching it on winuae. I'm really eager to see it. (However, you would probably be crucified about it not running on a real Amiga if it's spread so i'll understand if you prefer not to).

Stingray likes fixing prods so maybe he should have a go at it... :o)

Wow... damn, those tunes sound fantastic... can't wait to get my hands on the intro. Send it to z5 at pandora.be :o) I won't spread it. Honestly!