Many retrocomputers from the late 80s and early 90s had audio DAC hardware support. This includes the Amiga, Classic Macintosh, and PC's with SoundBlaster add-on cards. Despite the fact that the MP3 codec is designed to perform well at pretty low bit rates (<128 Kbps), these retrocomputers can't handle MP3 playback.

Below is an excerpt from the AmigaAMP System Requirements.

Basically AmigaAMP runs fine on any stock Amiga with at least a 68030-50 MHz processor. However, if you want to be able to play MP3 without downsampling and quality loss you need at least a 68060-50. Be prepared to face heavy system load! :-) If you've got a PowerPC you can play MP3 streams in the background without noticeable system slowdown at all.

What is the critical bit of computational capability that is so lacking in the earlier machines that makes MP3 playback infeasible?

up vote 26 down vote accepted

What's lacking is mostly raw number-crunching ability. The MP3 format is relatively lightweight, and can be implemented using only fixed-point math (no FPU required), but it still takes a fair amount of computation to turn compressed frequency-domain data into uncompressed time-domain data that can be fed to a DAC. This IEEE article quotes a minimum performance of 24 MIPS, and that is based on platform optimizations of the decoder.

Wikipedia says that the 68030 at 50 MHz performs at about 18 MIPS, while a 50 MHz 68060 would do 67 MIPS. Specific differences likely to be relevant are the much larger caches (8 kb versus 256 bytes), dual instruction pipelines permitting the CPU to execute two instructions at a time, and general optimization of integer math circuits.

  • 5
    @BrianH - Back in the day, if you wanted to FFT on a small system, you added a special extra processor called a DSP -'Digital Signal Processor'. As an example of such a product, I worked the Neurotrac II. We used a DSP for all all the heavy math (various flavors of FFT and filters on realtime and stored data) because the 68020 we used for disk and other I/O couldn't begin to keep up with 8 channels of EEG. Our current product (the CNS) uses a PC with a low-spec CPU to do 32 channels twice as fast, plus a LOT of other features the NTII didn't have. – Michael Kohne Apr 14 '17 at 17:24
  • 4
    @BrianH it's not lack of work optimizing FFT, and it's not lack of specialized instructions, it's just lack of raw processing power. MP3 decoding is both more involved than what you describe and actually doesn't involve an inverse FFT (but there is an inverse MDCT, a subband filter bank, stereo decoding, and some other interesting stuff). – hobbs Apr 14 '17 at 17:33
  • 3
    My memory from PCs is that a fast 486 could just barely decode low-bitrate MP3, while a Pentium-class machine could do it more easily. Which is in line with this answer in terms of MIPS, as well as dual pipelines. – hobbs Apr 14 '17 at 17:39
  • 4
    @BrianH, floating-point ability is irrelevant. MP3 is designed to be decoded using fixed-point (integer) arithmetic. – Mark Apr 14 '17 at 22:08
  • 2
    This IEEE article quotes a requirement of 25 MIPS: ieeexplore.ieee.org/document/4564625 – pjc50 Apr 21 '17 at 12:03

Mp3 is primarily a lossy compression format for audio. It must be decompressed, and the process needs a lot of CPU time (as for retro computers.)

Modern computers both have speeds good two orders of magnitude higher, and CPUs with specialized "multimedia" instructions that streamline operations like fast cosine transform. A trivial operation like "flip a byte backwards, bit-wise" on Amiga can take some 30 instructions. A modern PC will take maybe two.

The situation is somewhat similar for JPEG - I remember how my Amiga600 (7MHz) would take 20 minutes to display a JPEG that a PC (300MHz) would show in a blink of an eye. The CPU would suggest a speed-up to something of order of 20-30 seconds, but the multimedia instructions made all the difference.

  • For further comparison I remember something like less than 10s for an A1200 with 28MHz 68030/882. 20min does sound like a hard life! – nsandersen Apr 14 '17 at 9:42
  • I think you are talking about SIMD instructions, like I recall being marketed as "MMX" by Intel and "AltiVec" for PPC in the 90s. But i wonder what part of MP3 decoding needs SIMD instructions, and what type of instructions. – Brian H Apr 14 '17 at 15:02
  • 2
    @BrianH: Note early Pentiums struggled with mp3 too. – SF. Apr 14 '17 at 18:20
  • 1
    I remember somebody proposing a cheap and simple hardware solution to the "reverse the bits in a byte" problem: just connect a parallel input port and a parallel output port with a suitably wired cable! – alephzero Apr 19 '17 at 20:44
  • 2
    That is in the end building a specialized coprocessor ... out of 8 wires :) .... BTW, SSH logins can take M I N U T E S on 68k, 80486 and early SPARC machines.... – rackandboneman Apr 20 '17 at 13:36

Early 68k processors implemented a multi-cycle multiply instruction (70 cycles per MULx), so the inverse MDCT would likely be the limiting factor in terms of raw CPU time.

  • So to do the math, a 7MHz Amiga 500 would be able to do 100,000 multiplies a second (unpipelined, so unable to do anything else) which for a 44.1KHz stereo MP3 is barely over one MUL per sample per channel! I don't know if lookup tables or shifts and adds could be used instead but that sounds like a deal breaker to me. – user3570736 Jun 23 '17 at 6:46
  • It's not necessarily 70 cycles; for unsigned multiply it's 38 + 2n cycles, where n is the number of set bits in the multiplicand. So 70 is worst case (the 68000 performs only 16x16->32), and 38 is the best, with 54 being the average. So a 7Mhz 68000 would be able to do at least 100,000 multiplies a second. Assuming no wait states, though obviously they're not going to make a huge difference when so little of the cost is memory access. – Tommy Jul 6 '17 at 15:21
  • Whoops; forgot to cite my reference for that claim: oldwww.nvg.ntnu.no/amiga/MC680x0_Sections/timstandard.HTML — provides 70 as the official figure but the footnote conveys that 70 is a maximum and gives the formula as quoted. – Tommy Jul 6 '17 at 17:16

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.