[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Recode to Play MP3?

mdj wrote:

On May 21, 6:14 am, "Michael J. Mahon" <mjma...@aol.com> wrote:



Since continuous 11kHz sampled sound would only require a fraction of
this bandwidth, I'd say that the CFFA is not the speed limitation.


After thinking about it, I realized that the file server test may have
introduced some additional overhead, so I repeated a very simple FOR
loop BLOAD test, reading the first 32KB of a large binary file.

At 1MHz, the time to BLOAD 32KB was 0.92 seconds, for a net bandwidth
of almost 35KB/sec.  At 8MHz, this bandwidth rose to 41KB/sec, so
processor speed is not a major factor.



Out of curiosity I repeated your test on my IIe, which has no CFFA,
but instead a Rev C. SCSI card fitted.

With the Transwarp turned on (3.6Mhz), A 32KB BLOAD loop yielded 32KB/
sec. With it turned off, 26KB/sec


So at least a CFFA is faster than a Rev. C.


To get some contrast, I ran the same test against a RAM disk, which
yielded 160KB/sec. This figure is probably representative of an 8-bit
Apple II's "terminal IO velocity" :-)


I presume this was with the TransWarp enabled, since just a simple
(not unrolled) 1MHz move loop has a "bandwidth" of about 78KB/sec.


I don't have the determination to drag out a IIgs + RAMFast to do some
testing with that, and the test would have to be changed to read
successive chunks rather than the same chunk, but with a small delay
inserted between I'd imagine it's net speed would be far closer to the
latter test than the former.



This speed is plenty to support continuous playback.



It certainly is if the sound data is raw, and requires no post-
processing, but even a modest amount is going to necessitate double-
buffering, and 30-40KB/sec is going to be insufficient. Even the
overhead of a GUI could be enough to absorb sufficient cycles to cause
under run conditions.


The sound players we are discussing all play only raw, 11kHz sampled
sound, so the only post-processing requirement, the replacement of
$00 samples with $01 so as not to stop the DOC, is trivially done
within the move loop (at an average cost of another 2 cycles, which
drops the copy bandwidth to 68KB/sec), assuming that copies from RAM
to sound RAM are the same complexity as RAM-RAM copies.

Triple-buffering is inherent, in that file data must be read into RAM,
then copied to (the inactive) half of the sound RAM before the active
half is finished playing.  When the DOC toggles to the second half,
then the application can start copying the to the first 32KB.

As a result, there is the time for the file I/O, plus the time for the
copy to sound RAM, that must be accomplished before the DOC finishes
playing half of the sound RAM (32768/11025 = 2.97 seconds).

There should be plenty of time unless the protocol for filling half
of the sound RAM is really a mess.


Of course, the aforementioned applications were designed on hardware
with much better throughput than the CFFA. In the case of Oversampler,
I'd doubt that there'd be enough inefficiency in the application that
could be removed to make it work with slower IO devices.


As noted, I don't think there is a problem.  Didn't these apps work
with a Rev. C SCSI card?


I wonder how much extra hardware would need to be added to the CFFA to
get a dramatic improvement? I would suspect that adding a 512 byte
buffer and implementing the IDE/ATA readblock/writeblock in hardware
would eliminate a lot of round-trip-sync delay, but I don't know if
the PLD on the CFFA has sufficient gates for something like this.


The problem is much more fundamental--the CFFA does not have either
RAM or a microcontroller--the 6502 does it all.

-michael

NadaNet file server for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."