Re: RFC: 16-bit Sound Processor Design

[isc10327@nusunix1.nus.sg (ONG TAT-WEE)]

Jawaid Bazyar (bazyar@teal.csn.org) wrote:
: I'm in a hardware phase once again.  I'd appreciate any ideas/comments/
: suggestions you Ensoniq-lords have about a new sort of sound processor I'm
: thinking of banging out.  It's going to be 16-bit, utilizing the new
: 1-bit DAC technology found in newer CD player models (that results in
: better sound for less money than standard DACs).
: 
	Sounds good!  Great to hear that, Jawaid!

	Well, here's my wish list:

: What sorts of features does it need?

	Definitely compatibility with all current GS programs.  It
should also contain proper shielding to remove the hiss from ROM 01 GS.
So perhaps the sound from GS programs will be improved when playing thru
this card.  Also is a filter possible?  To filter out noise from sound
sources which have not been properly/cleanly sampled.  How about
supporting 16-bit sampling with sampling rate of at least 44.1 khz and
in stereo, saving directly to hard disk so the sample size is not
limited by RAM?  And hardware compression/decompression for sound?  How
about dynamic compression while sampling?
	And a good supporting software for the card, otherwise it'll
be pretty difficult for nonprogrammers to use.  The software should
include standard features found in current GS sound programs like Sound
Shop, Audio Animator, Audio Zap.  In addition, how about other features
like being able to change the pitch of the sample without changing the
speed of playback and vice versa (like MacRecorder).
	Above all, cost must be low.  I know it's kind of inversely
proportional to the features, but just try, ok?

: How many channels? 

	At least 8 channels, perhaps even 16 if the cost allows.  So we
can hook up at least 8 speakers to get octophonic sounds.  Hey, how
about software to decode and playback THX effects? :)

: How much memory should it be capable of using?  

	The card should be able to use the GS main memory like the
Amiga's sound chip.  Programmers should be able to reserve say 512k of
main memory to store their super long sound track and pass a pointer
containing the start of the memory location, its length, playback rate,
etc... and the processor on the card will take care of loading the sound
sample in main memory to its own memory when required.  It shouldn't be
like the Ensoniq where the software has to do the loading!  This will
take overhead off the software.
	Also, the card should contain sockets for 1-4 meg of sound ram
so that those who can afford it can add sound ram to the card.  Then the
software can load the sound directly to the card instead of using the GS
main memory.  Also, the sound ram can be used as a buffer during
sampling.

: How should it handle timing interrupts and such?

	Umm... Referring to the above question, how about using DMA with
cycle stealing for the first portion and DMA with burst mode while doing
sampling to hard disk?

: Since I know next to nothing about sound generation, I'm all ears (Gosh,
: Perot's such a cool guy).
: 
: -- 
:  Jawaid Bazyar              |   Ask me about the GNO Multitasking Environment
:  Procyon, Inc.              |   for the Apple IIgs!   
:  bazyar@cs.uiuc.edu         |   P.O Box 620334
:  --Apple II Forever!--      |   Littleton, CO 80162-0334   (303) 933-4649

- DOTW -