A.D.A. Amiga Demoscene Archive

  Welcome guest! Please register a new account or log in

  

  

  

Demos Amiga Demoscene Archive Forum / Coding / My Amiga 4k synth
 Page:  1  2  »» 
Author Message
Blueberry
Member
#1 - Posted: 30 Mar 2007 14:11
Reply Quote
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!
z5_
Member
#2 - Posted: 30 Mar 2007 19:35
Reply Quote
@blueberry:

Wasn't Planet Loonies the first and only 4k ever containing speech. Are there pc 4k's with speech?
Corial
Member
#3 - Posted: 31 Mar 2007 10:50
Reply Quote
I think the first 4k to contain speechsynthesis was Void3 by Kolor made in 1999. URL
Blueberry
Member
#4 - Posted: 4 Apr 2007 11:41
Reply Quote
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
Pezac
Member
#5 - Posted: 19 Aug 2007 21:44 - Edited
Reply Quote
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.
blakkhar
Member
#6 - Posted: 21 Aug 2007 00:25
Reply Quote
Yesterday I made some samples with it and start a mod. Thanks for the nice software Blueberry. :D
winden
Member
#7 - Posted: 22 Aug 2007 19:12 - Edited
Reply Quote
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
michael phipps
Member
#8 - Posted: 22 Aug 2007 19:16
Reply Quote
Now your talking my language hehehe...
Pezac
Member
#9 - Posted: 23 Aug 2007 16:32
Reply Quote
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.
Kalms
Member
#10 - Posted: 23 Aug 2007 17:41 - Edited
Reply Quote
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.
winden
Member
#11 - Posted: 23 Aug 2007 19:16
Reply Quote
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 ;)
Kalms
Member
#12 - Posted: 23 Aug 2007 19:25
Reply Quote
@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.
Pezac
Member
#13 - Posted: 24 Aug 2007 12:29
Reply Quote
@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.
Blueberry
Member
#14 - Posted: 18 Sep 2007 23:19
Reply Quote
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.
Kalms
Member
#15 - Posted: 19 Sep 2007 17:46
Reply Quote
blueberry: do you have any idea why the minimum-sample-length is 124 rather than 114? I've always found that restriction very curious...
Blueberry
Member
#16 - Posted: 19 Sep 2007 19:10
Reply Quote
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.
rload
Member
#17 - Posted: 20 Sep 2007 00:03
Reply Quote
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.
rload
Member
#18 - Posted: 20 Sep 2007 00:09
Reply Quote
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.
winden
Member
#19 - Posted: 20 Sep 2007 23:46
Reply Quote
[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.
Blueberry
Member
#20 - Posted: 21 Sep 2007 09:33
Reply Quote
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...
rload
Member
#21 - Posted: 6 Oct 2007 17:32
Reply Quote
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?
rload
Member
#22 - Posted: 6 Oct 2007 17:36
Reply Quote
Removing all chord notes and notes at 0 positions made it compile.
rload
Member
#23 - Posted: 7 Oct 2007 22:21
Reply Quote
It was a bug in asmpro. wow
rload
Member
#24 - Posted: 9 Oct 2007 23:34
Reply Quote
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
z5_
Member
#25 - Posted: 10 Oct 2007 17:46
Reply Quote
@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.
Kalms
Member
#26 - Posted: 16 Nov 2007 14:07
Reply Quote
@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?
rload
Member
#27 - Posted: 21 Nov 2007 12:27
Reply Quote
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?
rload
Member
#28 - Posted: 21 Nov 2007 12:31
Reply Quote
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?
z5_
Member
#29 - Posted: 21 Nov 2007 13:08
Reply Quote
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)
z5_
Member
#30 - Posted: 21 Nov 2007 18:02
Reply Quote
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!
 Page:  1  2  »» 

  Please register a new account or log in to comment

  

  

  

 

A.D.A. Amiga Demoscene Archive, Version 3.0