24

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?

Improve this question
1
  • 3
    Short answer: because CPU at that time have really slow multipliers, like 50 cycles per operation.
    – user3528438
    Nov 25, 2018 at 19:51

4 Answers 4

Reset to default
34

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.

Improve this answer
18
  • 8
    @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, 2017 at 17:24
  • 10
    @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, 2017 at 17:33
  • 4
    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, 2017 at 17:39
  • 4
    @BrianH, floating-point ability is irrelevant. MP3 is designed to be decoded using fixed-point (integer) arithmetic.
    – Mark
    Apr 14, 2017 at 22:08
  • 3
    This IEEE article quotes a requirement of 25 MIPS: ieeexplore.ieee.org/document/4564625
    – pjc50
    Apr 21, 2017 at 12:03
12

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.

Improve this answer
14
  • 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, 2017 at 9:42
  • 3
    @BrianH: Note early Pentiums struggled with mp3 too.
    – SF.
    Apr 14, 2017 at 18:20
  • 1
    I remember on my first Pentium system when mp3s were just becoming a thing, I had WinAmp set to play back my (128Kbps fixed bitrate) mp3s at 22khz @ 8bit instead of 44khz @ 16bit so that it would only use ~30% of the CPU and allow multitasking instead of using 80+% of the CPU to play back at full quality.
    – mnem
    Apr 14, 2017 at 21:42
  • 2
    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, 2017 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, 2017 at 13:36
9

Like others already answered: old CPUs does not have enough MIPS, and/or they are lacking instructions that would helped in MP3 decoding algorithm (remember that MP3 is standardized in 1995.).

Nice example of 1992. computer that can play MP3 out-of-box is e.g. Atari Falcon030 from 1992. Despite slow main CPU, MC 68030 at 16 MHz, Atari Falcon also have Motorola 56001 DSP chip (16 MIPS at 32 MHz) and he can replay MP3 at 16 bit and 44.1 kHz, even in multitasking:

Two examples from Youtube:

Improve this answer
2
  • 1
    Welcome to Retrocomputing Stack Exchange. Thanks for the answer; it'd be good if you used [link text](https://url.org) markup to add link text for those YouTube links. Check out the tour to learn how Stack Exchange works.
    – wizzwizz4 ♦
    Nov 23, 2018 at 19:22
  • The Falcon is a marvel; cf. youtu.be/WpwlZgQPCpk — yes, that's the base hardware. Other than a RAM upgrade.
    – Tommy
    Nov 24, 2018 at 4:58
8

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.

Improve this answer
3
  • 1
    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, 2017 at 6:46
  • 1
    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, 2017 at 15:21
  • 2
    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, 2017 at 17:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .