Re: Recode to Play MP3?

[mdj <mdj.mdj@gmail.com>]

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

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 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.

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.

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.

Matt