bh2@doc.ic.ac.uk (B Hogan) (03/04/91)
All these questions awaiting answers. Recently I've seen it stated several times that MEMC has 25.6Mb of bandwidth to dish out. Where does such an odd number come from? Can someone explain. I've just got hold of my first 8 channel sound tracker module. Oh dear... it almost cripples my A3000. Playing it when in any mode above 12 causes notes to be lost whenever the mouse is moved. It is at this point that Amiga owners leap up and tell you how wonderful all their extra hardware is. Isn't there any way to reduce the CPU requirements of the sound system? Why isn't it possible to just point VIDC (or should that be MEMC?) at a sample and say 'play this at so and so speed' ? After all this is analogous to what happens with the video output, isn't it? Why am I using so many question marks? Is the answer to all my problems 42? Bryan H. comp.binaries.acorn here we come :-))))
jroach@acorn.co.uk (Jonathan Roach) (03/04/91)
OK, as I posted the 25.6Mb/Sec bandwidth, I aught to explain where that number came from. The MEMC is clocked at 8 MHz, and thus, might be able to pull out 8M 4-byte words per second from the memory, ie 32 Mb/Sec bandwidth. Unfortunately, the RAM can't hack this speed, indeed, it can only hack 4MHz random access speed. However, it is possible to do a thing called 'page mode access' where the RAM can be accessed at twice the speed (approx) when accessing sequential locations. MEMC, when a sequence of reads is made, will do a random access at quad-word boundaries, and sequential accesses for the next 3 words, thus giving a time of 250nS + 3*125nS to access each sequential 4 words of memory. Working these numbers into a Mb/Sec rating ends up at 25.6 Mb/Sec. This difference between sequential and non-sequential accesses also gives the ARM its S- and N- cycle counts (the ARM hints at the MEMC when it wants sequential and non-sequential accesses), and it also gives the quad-word alignement optimisation techniques for ARM2 code (align the N-cycles where MEMC would be doing N-cycles regardless!) And for sound, here's a potted description of the sound system: MEMC DMAs the sound in blocks of 4-words (see above explanation why 4-words are a real good idea). Each block of 4 words contains, in your example of 8 channels, 2 samples for each channel. There is one sound DMA channel, which is double-buffered - this contains all the samples for all the channels. The way sound data comes from the original sample source to the sound DAC is as follows: The next DMA buffer is filled (this is triggered by an interupt from MEMC when it swaps to the DMA buffers). This involves the one of the sound modules calling each of the 8 sound generators to fill in its samples into this DMA buffer (here I assume the sound tracker module is using one sound channel per tracker module channel). If you have a PRM to hand read the section on sound, especially the example voice generator - this'll give you a feel of how many CPU cycles per byte there are involved in filling the sound DMA buffer (3.5S + 4N (the .5S is the looping overhead) + overheads between channels (small in comparison)) (S-cycle: sequential memory access cycle - one 8MHz clock tick; N-cycle: non-sequential memory access cycle - one 4MHz tick (2 S-cycles)). This works out at 1.5uS per byte (for an unloaded memory system - the more memory is transfered for the screen the longer this figure becomes - mode 15 uses about 1/3 of the memory bandwidth, CPU speed * 2/3, time per sample * 3/2). The sound system notifies MEMC that the next buffer can be used. MEMC finishes DMAing the last buffer, swaps to the new buffer and the process starts again. The DMA process is DMAing the data to VIDC which contains the sound circuitry. VIDC then pipes the relevant samples to the DAC and we have the sound. OK, where might this go wrong? Mostly, there's no problem, but it is possible that it takes so long to fill the next DMA buffer that MEMC finishes the previous buffer before the next one is available - this is overrun. Basically, the CPU is being asked to do too much in the time it has available to it (sound DMA slows the CPU too!). Why would the mouse affect this? Well, moving the mouse sends a whole stream of interupts to the CPU as the keyboard keeps the main machine up-to-date with the mouse movement. So, mouse movement can be quite a strain on an already heavily used machine, and might just send it into the overrun situation. Why overrun would penalise the notes starting (and thus, dropping them), I don't know - perhaps the interupt priorities mean the sound system is desperately trying to fill the buffers (and failing), locking out the tracker module, I don't know for sure. As for your question 'why isn't it possible to point VIDC (actually MEMC) at a sample', well, it is possible, (and at one of a small selection of speeds), but you lose all the structuring the sound system offers - nice things like notes, channels, DMA buffer handling etc. I hope this has answered your questions - I posted this in the expectation that others might be interested in the answer. --Jonathan