From: Michael R. Zucca <mrz5149@acm.org>
Date: Sun Mar 2, 2003  5:31:34  PM US/Eastern
To: John Klos <john@sixgirls.org>
Subject: Re: mp3 on m68k (was headless)

On Sunday, March 2, 2003, at 02:12  PM, John Klos wrote:

> Using optimised assembly, which is what the Amiga clients are, a 40 MHz
> 68040 can play many mp3s without breakup, but cannot play high quality
> bitrates. A 50 MHz 68060 can play all bitrates and still have a little 
> CPU
> left for multitasking, and can even play Ogg Vorbis, too.

Before we bother decoding we need working sound. :-) I've been playing 
around with SCSI DMA again on the AV and while I was looking around for 
specs on the PSC DMA engine, I noticed that Linux 68k had a header file 
that described the DMA engine as far out as the DMA channels for the 
sound chip.

It seems like the AV sound setup is pretty straight forward. The DMA 
engine runs continuously over a circular buffer. You specify to the 
engine the physical address of the buffer and a buffer length (or 
possibly it was fixed, I don't remember off hand). Now, for such a 
setup there is usually a "low water mark" interrupt that interrupts 
when the buffer is half full or empty. I assume that there is an 
interrupt line on the PSC that does just this (see the NetBSD headers, 
there are a few interrupt lines that we don't know of yet) or that it's 
wired up to the same line the ASC would be wired to on one of the VIAs.

With such hardware, you allocate a buffer (zeroed to start) and you use 
the interrupt to keep track of when you need to fill up the opposite 
buffer with sound data. (Wow! Double buffering!)

Even if we can't find the interrupt line right away we could probably 
make a "beep driver" by using a timer interrupt to know when to stop 
beeping like we do with the ASC beep driver today.

The Linux headers also point out a few of the sound chip's control 
registers (i.e. sound in level, headphones plugged in, etc.) The 
trouble is, they don't include the output volume register. That's 
something that probably can only be gleaned by disassembling the sound 
driver.

Anyway, I hope that's piqued somebody's interest :-)

> So a Quadra 840AV can do it, if someone is so inclined to port the 
> Amiga
> client to NetBSD. What'd be way cooler, though, is if NetBSD had a
> cross-platform interface to the DSPs on any particular port. Then 
> someone
> could make an MP3 and an Ogg decoder (and maybe encoder) that used the
> DSPs on the AV Quadras and the NeXT machines...

Well, I guess a /dev/dsp with ioctls to load, run, and stop code would 
be good, along with an mmap interface to map DSP memory to get results 
and synchronize.

The general hardware layout diagram of the AV in the Apple docs seems 
to indicate that there is an interrupt line that goes _to_ the DSP but 
not the other way. I assume this is either a reset interrupt or a 
simple "door bell" interrupt so that running code fragments could be 
interrupted to give a scheduler a chance to load and run new fragments 
or other activities.

So a more advanced architecture for the DSPs might be to write a little 
cross platform code-fragment scheduler. Then you pass code fragments 
you want to run to the scheduler and have a data passing and 
synchronization API to talk to your DSP code fragments as they run. 
Though, I think such a thing can wait until after we even know where 
the DSP lives in the AV's address space :-)

-- 
----------------------------------------------
  Michael Zucca - mrz5149@acm.org
----------------------------------------------
  "I'm too old to use Emacs." -- Rod MacDonald
----------------------------------------------