From: bull@vaxc.cc.monash.edu.au
Newsgroups: comp.sys.amiga.hardware
Subject: Re: AA sound chip. Specs?
Date: 7 Oct 92 21:18:24 +1000
Organization: Computer Centre, Monash University, Australia

mks@cbmvax.commodore.com (Michael Sinz) writes:
> barrett@iastate.edu (Marc N Barrett) writes:
>>bull@vaxc.cc.monash.edu.au writes:
>>>
>>>        Were any details about the AA soundchip (Lisa?) released by
>>>C=. I realise that Lisa isn't available just yet, but since my primary
>>>interest in the Amiga is music related, having some idea of what the
>>>next generation sound chip will be like would be useful to me.
>
> We did not release an updated audio subsystem yet.  AGA mainly is a graphics
> update.

        Fine. Just asking. If the design isn't very advanced yet, I'd like
128 sound channels please, so I can have a seperate channel for every
single instrument in a symphony orchestra. 8-) Oh, make the channels
24 bits wide while you're at it. Merci.

>>   You are out of luck.  Commodore has not improved the Paula sound chip at
>>all in the AGA chipset, and has not said anything about any plans to release
>>an update for the Paula chip any time in the near future.  Commodore may
>>release a card with a DSP on it capable of 16-bit sound, but it will not be
>>compatible with the Paula chip and software support for it will be severely
>>lacking.

        Once again, everyone's favourite graduate of "Hillbilly Bob's
correspondence school of computer design and development" (MB) exposes his
general lack of understanding. Marc, do the terms "Operating System",
"Device Driver" and "Device Independence" mean anything to you?

        How could you add a DSP to the Amiga and still stay compatible
with current software (at least with software that uses the OS properly)?
Lets start with an AutoConfig card for the DSP, add a device driver called
dsp.device and modify audio.device which handles the data passed to Paula.
The trick here is to be able to set a switch in the OS which tells it
to redirect data from audio.device to dsp.device. Since programmers are
*supposed* to call audio.device to use the sound channels, they don't have
to worry about where the data goes. The driver dsp.device is given the
data and plays it. I am assuming that dsp.device is designed to do
everything Paula can do (vis a vis audio), and more.

        What I'm talking about here Marc, is Device Independent Audio
(what an amazing concept ;). The only programs which will have a problem
with this are the ones that ignore the OS and hit Paula directly.

Letting the OS perform invisible redirections of data from audio.device
to dsp.device isn't a particularly mindboggling idea. It would probably
require a new audio.device, but a Paula upgrade would need a new driver
anyway (are you reading all of this Mike?).


> I love the way you slant your responces...  Here you first point out that
> Paula was not enhanced and then say that we might do a DSP board with
> advanced audio capabilities but then say that it would be incompatible
> and software support would be a problem.
>
> Well, lets say we did upgrade Paula to do 16-bit sound with 32 channels
> (I am not saying we will, this is just an example)  How much software
> support would there be?  Most current software either uses audio.device
> with 8-bit samples at 28kHz or less sample rate or it hits the hardware
> directly.  In either case, the enhanced features of the new Paula would
> not be utilized either.  So, maybe the Paula on the A4000 has all of these
> features but we just did not talk about them or give you the register
> map.  Who would know the difference?

           Bull@vaxc.cc.monash.edu.au  OR  bull@monu1.cc.monash.oz
                    DOD# 251  '84 VF 750   Closet Ducatisto
             Disclaimer. If you love your llama, let it lambada.