MpegDec purports to be able to play MP3s on any Mac with at least a 68040 processor, and it may be able to function on 68030 Macs as well. However, no 68k Mac I have tried has the ability to play a 128 kbps stereo MP3. There is simply not enough muscle in the old 68k Mac platform.

Overall, lower quality MP3s work very well on 68k Macs, and even some higher quality MP3 files will play, albeit with the entire Mac OS freezing until the file finishes. Once you get to 128 kbps stereo MP3s, the Mac OS tends to lock up, and the MP3 will stutter during playback.

MpegDec
I should note before there is further confusion: MpegDec continues to support playback of MP3s on 68k Macs without needing any further tomfoolery (see MpegDec: Play MP3s and Streaming Audio on 680×0 and Old PowerPC Macs).

On a related note, a reader recently reported the ability for MpegDec to properly play 160 kbps VBR MP3 files without skipping on his LC 475. I’m waiting to hear back about further details on his particular LC 475, but this 25 MHz 68LC040 powerhouse did the deed for him.

Occasionally, I have gotten higher bit rates to play without too much hassle, but MpegDec will commandeer the system’s resources. Thus a user will discover the user interface has become unresponsive until the track or playlist is done playing. A cooperative (not preemptive) multitasking 0S and 68k Motorola processor can only work so much magic.

If one doesn’t mind the ability to not pause, stop, quit, or otherwise interact with the computer while MP3 files are playing, then MpegDec is a little more flexible than I may have alluded to in past installments of this series. I should note the setup I used to test the reader’s assertion: PowerBook 520c, 25 MHz 68LC040 processor, 12 MB RAM, 140 MB hard drive, Mac OS 8.1 with AppleTalk off. MpegDec 3.1.1 44100 Hz, 166 kbps VBR MP3 – 2:22 long.

Not quite flawless, but the PowerBook was darn near close for a 12-year-old computer. Also, the user interface was not completely unresponsive; I was able to click the mouse a couple times and the pause function registered after a 5-6 second delay. Not so terrible after all.

I’m thinking a faster desktop hard drive, either SCSI or ATA, may fare even better. More RAM and possibly a less taxing OS (such as System 7.5.5 or 7.6.1) may have improved performance a little more. I’ll see what sort of further tests I can run and report back.

Fact is, every Mac ever made supports 230.4 kbps over the serial port.

So one thing I'll try is building an x86 command line player from the source, as that seems to be included in the source.

We Don't Miss The Past
Writing an audio player in the classic Mac OS is rather unpleasant. All is well and good until the first time you click open a menu and the music stops playing in the background, and you suddenly have the sinking realization that because classic Mac OS only has cooperative multitasking, your audio player is not getting any processor time while the menu is held open.

Obviously this won't do, so you start modifying the code to run at "interrupt time" -- a privileged execution level where the OS can't neglect to run your code. Then you discover the joyous restrictions of working at interrupt time: no allocation, deallocation, movement or otherwise fondling of memory allowed. No calling into the operating system toolbox, which in turn means no filesystem access, limited network and sound output access, and absolutely no GUI updates. Oh, and do everything you need to do in the fewest number of milliseconds possible, otherwise the mouse cursor will start to chop-chop-chop around the screen.

One false move in interrupt time and, hey presto!, down comes the entire OS, and it's reboot time. I wonder how many times I had to reboot my Mac while writing Audion. Yikes. Thank the heavens for Mac OS X.