I was wondering the other day, would it be possible to listen to a midi on a C64 while writing a program or something. I mean it did have a sound chip that would technically just get some new buffers every few seconds, although I imagine the lack of multithreading would make it difficult, but games have found a way, right?
So was there a way to load music on an old PC (70s-90s) and when was it possible for the first time? Also what would it be like?

  • 1
    Not quite what you had in mind but 128 Spectrums was possible via interrupts to have sound via the AY-389-12 chip whilst Basic was in operation. Unlike the "beeper" which held everything up. Interrupts are your good friend here. I cannot find a relevant code snip though to hand.but most games with in game 128 music (ish) that I examined followed similar base principles. Amstrad CPC also used a Z80 CPU and the same (iirc) or almost the same sound chip too so one could say with high probability the same coding methods were used, albeit at different addresses and ports no doubt.
    – AndyF
    Commented Feb 13, 2020 at 18:54
  • 2
    The AY uses a programmable clock divider to produce output waves as a function of the input clock rate; the CPC's is clocked at 1Mhz whereas the Spectrum's is clocked at ~1.77Mhz, so you'd also want to adjust the pitches you were writing. There'd by some aliasing because pitch control isn't very precise, but I can't quantify that offhand within the useful range of options.
    – Tommy
    Commented Feb 13, 2020 at 19:08
  • 7
    This is more opinion than a real answer, but I think you would have had difficulty with most of the 8 bit generation of machines. I suspect, like anything, with clever programming you could 'make' this work. But the first time I ever just 'fired up a program and listened to music' while working was on my Amiga. By that time, you could just play Mod files endlessly while coding or bbs-ing or whatever... I suspect this was common on early 16/32 bit systems... - by the 90's WinAmp was whipping the llama's ass...
    – Geo...
    Commented Feb 13, 2020 at 20:05
  • 3
    I remember coding an interrupt based music player on 1983 8-bit Oric (6502/AY sound chip). You could do anything while the music was playing: basic, asm.. This was possible because you only sent play/stop order, and you hadn't to feed the sound data byte by byte to the sound chip Commented Feb 14, 2020 at 2:56
  • 2
    @AndyF I remember a utility on the Amstrad that would play music (the Blue Danube if I remember correctly) while you were using BASIC. BASIC wasn't noticeably slower and the music was smooth except when doing floppy disc IO such as cat, save, and load.
    – CJ Dennis
    Commented Feb 16, 2020 at 5:11

19 Answers 19


In theory that would have been possible from the very start. After all, music doesn't need much bandwidth (*1), especially when using synthesized form like with a sound chip such as the SID.

In reality the software structure of (most) machines in the 70s and 80s would not support this. They were single program, single tasking machines and the OS was not running in parallel in the background, but rather a toolbox.

Any solution to have two tasks running in parallel would have required specific software to do so, programmed in a way not to disturb each other. Quite rare at the time, when every program was made as if it owns the machine.

Bottom line: While the hardware was capable, common software wasn't.

Now, having said that, one of the very first dedicated home computers, the TI 99/4, could have pulled it off. Despite the bad rep the system had, it was one of the finest available - clearly showing an effort, by engineers coming from a mini computer world, to create an integrated environment. Its system software had a function that could play sound/music sequences in the background without interfering with foreground applications. It could also loop it.

In addition, as Peter Parker reminds us, the TI had the unique feature of being able to mix an external audio signal with its output (*2). So a setup using an external source, like a tape, was possible.

So the answer may be rather 'yes, but', as this would, while being transparent, still had required a bit of cooperation of the foreground application to enable and setup the music to be played.

*1 - Bandwidth needed for high quality uncompressed is ca. 50 KiB/s (*3), for synthesizer (sound chip) based music less than 1 KiB/s. Bandwidth of typical 1970s Microprocessor systems 300-1,000 KiB (C64 a bit less than 1,000 KiB/s). Early PC (8088) ca. 1,200 KiB/s. AT class (mid 80s) started already above 3,000 KiB/s.

*2 - In fact, it did not only allow addition of sound, but was prepared for video as well. As said, it was a quite nice design, way ahead of its time.

*3 - It has been criticized that this is way less than the 172 KiB/s a CD uses. True. But that's one definition (also one that resulted from video recording features). Audio sources of the time would be FM-Radio at 15 kHz or compact cassette at 12 kHz (even the best Nakamichi decks with 1.2µ heads couldn't make it past 20 kHz - damn physics :)). So a sampling rate of 24 up to 40 kHz would cover everything at the time, with 24 kHz already passing as HiFi.

This is about (home) computers from the 1970s onwards, so assuming a 16 bit D/A converter seams a bit frivolous. Similarly for stereo. Equally important, the audio signal was usually transmitted as part of video to be played by the TV set. Analogue TV limits Audio to 25 kHz in most places of the world - and was, at the time, usually mono.

Bottom line, 50 KiB/s is a good assumption, rather at the upper end.

  • 3
    @AndrejaKo "... 16 bits * 44100 kHz sampling rate * 2 channels = 705.6 kB/s or around 690 KiB/s" - I think you made a mistake in the calculation; the answer should be 176kB/s (172KiB/s).
    – marcelm
    Commented Feb 14, 2020 at 9:56
  • 4
    I used the cassette/datasette of the TI99/4a to listen through the TV-Loudspeakers while I was programming. The TI looped the sound to the TV. While this was a cheap trick, it felt like my computer was doing 2 things in parallel.. Commented Feb 14, 2020 at 10:06
  • 6
    @AndrejaKo: "CD quality" was meant to be not just "high" quality but perfect. Human hearing ends at 20 kHz, so a sample rate of 40kHz would theoretically be sufficient but the designers wanted to make sure that CD players reached the 20kHz limit even with poor filters so they intentionally added a 10% margin. But 32 khz mono at 8 bits G711 (32KiB/s) is pretty decent quality.
    – MSalters
    Commented Feb 14, 2020 at 10:33
  • 4
    @MSalters Uh, no, CD was never meant to be perfect. If somebody told you that, they were likely trying to sell you a CD player.
    – JeremyP
    Commented Feb 14, 2020 at 13:51
  • 6
    @JeremyP This document by Monty from Xiph.org goes into detail on why it's enough. Even if you believe that ultrasonics induce audible harmonics, distortion is hardest to eliminate at the extreme low and high ends of an amplifier or speaker's range, so what do you think will happen when you drive devices rated for 20-20,000Hz with ultrasonic signals? (Gear that operates outside that range is pricey. The improved quality you're hearing in things like 24/192 music is down to better mastering for a premium product.)
    – ssokolow
    Commented Feb 16, 2020 at 12:59

On the generic early-nineties x86 systems I'm familiar with at least, redbook CD audio playback on IDE CD-ROM drives is asynchronous and autonomous. The drive would connect to the sound card through a four-pin stereo audio connector to provide CD audio as another audio source to the mixer.

You could use a CD music player program to control track selection and playback directly, but you could also just press Play on the CD-ROM drive itself and it would play music through the sound card without any intervention from the PC, allowing you to listen to music while using EDIT or other software.

  • 15
    Not even necessarily through a sound card. I remember having a CD-ROM that had a 3.5mm audio port, and since my PC at the time had a very basic sound card, my speakers would be plugged into CD-ROM.
    – bazzilic
    Commented Feb 14, 2020 at 10:16
  • 4
    Back in the day, I had a CD drive with its own phone connector and a play/pause button. You could plug earphones into it and listen to a CD even without any software running, if I recall correctly.
    – Renan
    Commented Feb 14, 2020 at 11:46
  • 3
    By far from "earliest", though, and it's not actually the computer playing the music. You were basically using the CD-ROM as an audio CD player, with the main computer not being involved at all.
    – DevSolar
    Commented Feb 14, 2020 at 13:18
  • 1
    The first incarnation of Tomb Raider (and possibly Carmaggedon) had all the music on the CD (it was a proper enhanced audio CD that would play on any* CD player), and would play that through the onboard soundcard, thereby leaving the main processor to handle any sound effects the game required
    – Neil
    Commented Feb 14, 2020 at 16:22
  • With appropriate software (whether Windows 3.1/95 or higher, or something like a modern *nix operating system), any 1990s x86 system should be able to play an uncompressed digital audio file in the background while multitasking. Decoding a codec like MP3 in real time does need a Pentium though.
    – RETRAC
    Commented Feb 14, 2020 at 16:56

The topic mentions PCs but as you mention C64s specifically in the text, I can note that on the C64 it was not uncommon for utility software to have built in music (especially in the tools centered around the needs of the demo scene).

Of course, that is not the same as a general purpose music player.

Music was generally not really made using MIDI or audio buffers in any modern sense, it was software directly manipulating the parameters of the on-board synthesizer chip.

It's trivial on the C64 to drive the music from a raster interrupt, as long as nobody else is stepping on the memory or interrupt control. That means that you can perfectly well load some SID music to the $C000 RAM area (beyond BASIC space) and have that play merrily whilst programming in BASIC.

As there is no coordination of such resources, in practice a general purpose solution did not exist. As Raffzahn notes, every program was made as if it owns the machine.


The Amiga was the first system where I pulled this off: It was not streaming music, but listening to so called "MOD"s, small data chunks of samples and instructions how to play them. There is still an alive(?) scene for this. These Mods could be played in the background on Amigas Multitasking OS, while you were doing something else.

Update: If you just want to listen to "real" music with lyrics the Amiga could pulled off this as well, but uncompressed 8-bit samples taking up the whole disk/memory(for one song), so you could not work in parallel. However sometimes I played this disk and imagined I would be soon proud owner of a digital music library: https://www.youtube.com/watch?v=_UnVy9w0xKk

Later PCs with Win95 support could be playing music as well, however for MP3 encoding you would need some (>100 MHz) pentium class CPU (if you want to work in parallel), while playing WAVs was (still )forbidingly expensive on HD-Memory (1995 a common HD was 1-2GB in size..)

  • 2
    The Inertia MOD player (and probably others too) on MS DOS was running in the background as a TSR program. So you could listen to MOD files while working. This was around 1994.
    – Jan
    Commented Feb 14, 2020 at 12:47
  • 1
    According to Wikipedia the Amiga program introducing the mod format was released in 1987.
    – Edders
    Commented Feb 14, 2020 at 15:46
  • 1
    The later 486-class processors could play MP3s at the full bitrate, but the older ones (DX2-66 or DX2-80) could only manage 80 kib/s. I know for sure that the Am486-133 processors could do it. Of course, this would leave precious few CPU cycles to do anything else. Commented Feb 16, 2020 at 22:58
  • @masospaghetti: I am a bit vague here, because "working in parallel" means something different for everybody. I have a Pentuim 75 MHz here and it stutters on most of my mp3s. I recalled to use my pentium 133MHz back in the days to listen to some music while working. Commented Feb 19, 2020 at 8:48
  • @masospaghetti 128 kpbs or 160 kbps with a DX2-66 if you selected Mono playback on Winamp ;) Also, I remember that Linux could do a bit better than Win98 in that regard
    – golimar
    Commented Jul 22, 2021 at 10:59

The first time I did this was on an Atari 400. Was a hack. I found out only one track was used for the program data, leaving the other one for audio. Great! I prepared a tape with some music recorded off the radio. While in basic, I could press play on the 410 data recorder, and start it with POKE 54018,52 (which I just had to go look up) to start the motor.

The audio track would play through the TV speaker.

I had some idea about including audio with a program doing something else, and the listen while computing happened a few times as kind of a test, proof of concept. What I ended up doing was just some programming on the Atari while letting the music play.

But, that's not really in the spirit of this question.

If one had the storage, playing a WAV file could happen fairly early on. I consider playing an MP3 file a more challenging test, and one early machine surprised me!

The earliest machine I listened to mp3 files on reliably was an SGI Indigo Elan. It has an R4K MIPS CPU, and a system clock speed of 30 MHz! I used a great little command line program called "amp" to play mp3 files. On a side note, that program has excellent accuracy, and was the basis of many players to come in the future as it was optimized for performance. Originally, the question was whether it could play mp3 files at all.

Turns out that machine could play up to 256 Kbps MP3 encoded files reliably over an NFS share, and doing that would take something like 90 percent of the CPU. Lower bitrate files took less, and when the computer was just acting as an X-Window terminal to some other machine, one could totally listen to music and get work done with only the occasional stutter.

It's release year was 1992, and I did these things sometime around '98? Hard to remember now. What I do remember is I ended up with one of these machines and decided to see what could still be done with it. Real time, quality playback at 30 MHz was impressive to me personally.

On suitably equipped and configured PC machines, CD playback was easy and ran through an input on the sound card. I did that fairly regularly on 486 and above machines.


At an 8 kHz sample rate, an Apple II would only hold about 5 or so seconds of raw uncompressed audio (plus the code needed to play them, either via add-on DAC board or 1-bit PWM). Compressed audio would need maybe at least a few orders of magnitude more compute performance than the very roughly 0.2 integer "MIPs" offered by a 6502 to decompress audio in real-time (which usually requires MACs, integer multiplies, or even a few MFLOPs).

So, no. Not without external hardware (DSP chip, banked memory expansion, etc.)

Powermacs (PPC 601, et.al.) made it reasonably possible (running AIX?). Not sure about the 68040 Mac with the DSP chip.

  • 2
    This is more an issue of software (can the computer multi-task) than hardware. On the Mac side of things, I expect it would be possible with the advent of MultiFinder in 1987. No, you're not going to be playing MP3s, but the hardware had more than enough computing power to do simple MIDI synthesis in the background while you typed away in ClarisWorks.
    – Mark
    Commented Feb 14, 2020 at 3:20
  • 1
    Halley Project had 10 or so seconds of sampled audio as its intro, so it was definitely possible to play back. Of course, that isn't quite the same as "listening to music while working".
    – Coxy
    Commented Feb 14, 2020 at 6:58

I wrote a music player on my 1983 Oric Atmos, and some other people already did that before me.

The Oric uses a AY-8912 soundchip. You can send orders to play waveforms with or without varying envelopes. The order is just a write into a register. Can be done from within an interrupt and the sound is issued. It doesn't take a lot of CPU.

On the other hand, a few programs tried to do speech synthesis, and in that case, that meant feeding the sound chip with data all the time (since the Oric didn't have sound DMA), hogging the CPU: not possible to do something at the same time.

The Amiga has DMA & a dedicated chip to play samples from memory without CPU intervention. The same principle can be applied to a higher level. Playing music doesn't cost a lot (unless if you had to perform real-time mix to overcome the 4 channel limitation)

On any computer with a beeper or any device, even rudimentary/monophonic (like yesteryear IBM PC compatibles beepers), and a timer you could set up a routine that plays sounds by sending sound orders to play notes, as long as the device supports taking a "play a note" order. This doesn't cost a lot of CPU (and the result isn't specially beautiful either but who am I to judge ?) and you can perform other tasks at the same time. But was considered a hack before modern multitasking home systems existed.

However quoting wikipedia:

The PC speaker was often used in very innovative ways to create the impression of polyphonic music or sound effects within computer games of its era, such as the LucasArts series of adventure games from the mid-1990s, using swift arpeggios. Several games such as Space Hulk and Pinball Fantasies were noted for their elaborate sound effects; Space Hulk, in particular, even had full speech.

However, because the method used to reproduce PCM was very sensitive to timing issues, these effects either caused noticeable sluggishness on slower PCs, or sometimes failed completely on faster PCs

So remaining simple was the key or it was the only thing the machine would do.


to load music on an old PC

It sounds like your expectation is that you could load up a CD of The Go-Go's into disk files, and play it in the background while you work. That won't work on 70s-80s machines, as they lack either the disk space to store even compressed music, or the computing power to decompress it on the fly. It starts to become possible in the mid-90s, but it really, really requires pre-emptive multitasking OS's such as Windows 95 or OS X. The music decoding needs CPU when it needs CPU, otherwise there will be breaks and gaps in the playback, and those are unlistenable. Which is also when disk space and CPU got to the point where compressed music was possible. When I went to a video trade show in 1992 and saw my first video editing station (using a wall of those massive, 5.25" 9GB hard drives), I knew consumers would have PC-based music soon.

I mean it did have a sound chip that would technically just get some new buffers every few seconds,

You realize for intelligible recorded-music playback, "a few seconds of buffer" would be bigger than the main RAM on a whole Commodore 64, right? You know how long a 1541 hard drive takes to load 64KB from disk... it couldn't possibly keep up, even if the disk held the megabytes needed.

Around 1980 we became aware of the Compact Disc standard, and that made perfectly clear why recorded music wouldn't be coming to computers for a loooooong time. The sample rate was 44.1 KHz (and that was considered minimal); and 16 bits per sample per channel. Or 64KiB every 0.74 seconds, or 0.37 seconds if stereo.

The beepy boopy tones that passed for music in 1980-ish computer games - well, that's another deal entirely. All you need for that are two ingredients: an audio chip capable of sustaining a static tone unattended, and a periodic interrupt such as a vertical-blank interrupt occurring 50 or 60 times a second. That is something that any post-1977 home PC had - not the initial Apple II, PET and TRS-80; but the next round -- Atari 800, VIC-20 and yes, C-64.

But there are still no buffers. So code needs to count out each beat -- and ramp, change or silence the tones at appropriate video frames. That code is very achievable on these ~1 MHz 16-64KB machines with room for a game also.

although I imagine the lack of multithreading would make it difficult, but games have found a way, right?

Well, thanks to the vertical-blank interrupt, the music routine does in fact have pre-emptive multi-tasking, i.e. multi-threading. That's how games do it; and I've written code that let me play such 1980-tier music while coding.

It wasn't worth it. It's super cute to have Bach's preludes and fugues beeped out by the onboard sound chip... for about 2 listens. After that, you really need a game to distract you from how bad it sounds. Back in the day, every programmer had a drawer full of cassettes or CDs containing actual music.


Any computer with...

  1. a dedicated sound generator chip (one that can oscillate on its own, without needing constant hand-holding from the CPU to drive the waveform) and

  2. video raster or timer interrupts (which allow you to write an interrupt service routine that will, at specific intervals, periodically update the pitch and volume registers of the sound generator chip, typically guided by sequenced note data not much different from a player piano roll)

...can technically do this. This includes most 8-bit home computers of the 1980s.

“Megasound Music Editor” (a Commodore 64 music sequencer by Jori Olkkonen) displaying the raster time usage of the playback routine in the borders
Megasound Music Editor (a Commodore 64 music sequencer by Jori Olkkonen) displaying the raster time usage of the playback routine in the borders.

When your playback routine is driven by hardware interrupts, your main program does not need to know or care about the sound playback. This is a rudimentary form of multitasking. For instance, the Commodore 64 (which you mention) and most of its contemporary competition could easily do interrupt-driven music playback, hardware-wise.

Of course, on the early 8-bit home computers, there were no standards for such thing. You could only do this if your main program did not set up the same interrupts to do something else, and did not use the memory locations occupied by your music playback routine and sequenced note data.

Also, there was no common, ”standard” format for storing or sharing the music files. Each computer/game musician generally created their own formats and wrote their own playback routines, and also sequenced their own compositions in a self-written, custom-made music editor/sequencer tool.

The MIDI standard was established in 1983 but would have been an overkill for such purpose; it is a bit too verbose and too generic for the limited resources of the home computers of the era — at least when considering the typical uses of music playback on those systems, such as games using the internal sound generator chip. A custom, sequenced music data format — designed to closely match the capabilities of a particular sound chip — would generally serve the needs better, and allow taking in account the practical limitations related to storage space and to the CPU time that can be allotted to the playback routine.

• • •

Still, the specific case you mention — playing back music while programming in BASIC on the Commodore 64 — was and is fairly achievable. ”Normal”, simple hobbyist BASIC program does not usually use interrupts for anything (that is, for anything else than what the Kernal does for the program while handling the keyboard and other I/O, and blinking the cursor), and there are memory areas in the C64 memory map which are normally not used or accessible (accidentally overwritten) by BASIC programs.

Playing back music on the C64, in the background, would involve loading a machine-language music playback routine — along with sequenced note data — into an unused, “safe” memory area (say, the one starting from the address $C000) and calling its interrupt setup routine, typically by issuing a SYS command from a BASIC program, or from the BASIC interpreter’s immediate mode. Once done, you could have music playing in the background, driven by interrupts, while still being able to program in BASIC and run BASIC programs the normal way.

You can actually see something like this in action if you try out the C64 game Smurfen:

The Commodore 64 game “Smurfen”
The Commodore 64 game Smurfen.

The game logic is written mostly in BASIC but there’s an interrupt-driven, machine-language music playback routine.

If you press the RUN/STOP key while the game is running, the computer will break out of the BASIC program — but the music (a SID rendition of Michael Jackson’s Billie Jean, of all things!) will continue playing in the background. You can work in the immediate mode of the BASIC interpreter, or even start writing a new BASIC program on your own, all while listening to Billie Jean.

• • •

As other answers note, a general way to do the same only materialized when home computers started getting multitasking operating systems, such as the AmigaOS, or OS/2, designed from the ground up to run several processes at the same time, without them stomping on each other’s feet.

Being able to easily share music also required establishing “standard” computer music formats, such as the 4-channel MOD format, and the MIDI format, and the respective music player applications for them, instead of having to share a runnable program (custom playback routine) with embedded music data stored in a custom format.

Amiga 500+ playing back a ProTracker module file (mostly sample-based rendition of Haddaway’s “What Is Love”) on Workbench 2.1
Amiga 500+ playing back a ProTracker module file (mostly sample-based rendition of Haddaway’s What Is Love) on Workbench 2.1.

These developments happened primarily on the 16/32-bit systems, finally allowing people to share bare music files (sequenced note data) e.g. in the file areas of the dial-up BBS systems of the era, independent of playback code, and enabling listening to music in the background while working on something else, paving way for later digital music formats with similar usage patterns, such as MP3.

• • •

To summarize, I would say being able to play back sequenced multi-channel computer music in the background while working in productivity applications — without any special considerations, or needing to jump through hoops; just by firing up the music player and forgetting about it — was a concept likely introduced “to the masses” with AmigaOS and OS/2, both of which multitask natively in a preemptive fashion.

This is not to say the earlier systems would not have been able to do similar things in some special cases. But the non-multitasking systems — or systems that would multitask ”co-operatively” — were much more limited with regard to this usage scenario. Systems like AmigaOS and OS/2 made the feature work like we expect music playback to work on a computer today, and gave the first “taste” of such concept to many people.


Was definitely possible on an Apple IIGS (and I expect Amigas and other 16 bit systems of the same vintage) to play music (think midi synthesized, not sampled at CD quality for any length of time) and write documents


So was there a way to load music on an old PC (70s-90s) and when was it possible for the first time? Also what would it be like?

See & hear it below. 1970 (maybe before). The PDP/8-e was introduced in 1970.

This depends on what you accept as a "PC" and what bar you set for "music".

A PDP8 was an expensive tool, or toy, in the 1970s, but was as close as one reasonably got for an 'off the shelf PC'.

Here is a video of a restored 1971 DEC LAB-8/e {PDP-8/e} playing music - on a radio via RF reception, or directly by speaker (I think).

I've set the video to start at 2m-5s. The excessively enthused will want to then go back to the start.

Music it is, then ...

enter image description here

The music is being played on the handheld radio!

enter image description here


Reviving a PDP/12 - music mentioned along the way

The PDP/12 was NOT a PDP/11 successor or variant. It was a PDP/8 with analog add on.

From Wikipedia: PDP-8/e

" ... The PDP-8/e was a model of the PDP-8 line of minicomputers, designed by the Digital Equipment Corporation to be a general purpose computer that inexpensively met the needs of the average user while also being capable of modular expansion to meet the more specific needs of advanced user. The first was built in 1970 and was among the first ever minicomputers and this one was small enough to fit in the back seat of a Volkswagen Beetle Convertible. It originally sold for $6,500 but after 18 months the price dropped to $4995 to make it the only computer under $5000 available at that time. ..."

  • 3
    Nice. I was half expecting the tune for, "Daisy, Daisy give me your answer do ...". ;)
    – RichF
    Commented Feb 15, 2020 at 22:38
  • Now the interesting part in the question is "listening to music AND WORK AT THE SAME TIME". I really doubt the PDP-8 could do that. (And pretty all computers could produce music with enough ingenuity, even very early ones).
    – dirkt
    Commented Feb 17, 2020 at 13:20
  • @dirkt I have very little doubt (leaving a very small trapdoor :-) ) that the PDP-8 could do both, with enough effort. At that stage "enough effort" was required to do almost anything. The later famed Z80 managed to walk and chew gum (in that case display video and "work at the same time" by processing in the display flyback periods. The music program seen here appears to produce "music" by operating the processor in loops of appropriate delay. Adding small gaps between notes for "other uses" is hardly harder than doing anything else on a PDP8. 8 instructions. No SUB (only TAD (or TADD?) ... Commented Feb 17, 2020 at 14:02
  • ... to help you not forget it's 2's complement add, so who needs subtract. Subroutine returns stored in memory as jumps at the start of the subroutine (Core! :-)), ... . Memory suggests (maybe wrongly) that memory started at 256 words. || BUT, yes, it would be as hard as most of the rest of "normal" on a PDP8 :-). Commented Feb 17, 2020 at 14:04
  • Just in case: I've experience using a real PDP-8, and "adding small gaps between notes for 'other uses'" is NOT trivial. In particular if you want the "other uses" to be existing software, like the OS. "Enough effort" here means "rewrite all existing software". And still it probably wouldn't be practical, because it would be much too slow. Remember, you want to do normal work while listening to music.
    – dirkt
    Commented Feb 17, 2020 at 14:26

Around 1997 I had a Pentium 133MHz and 32mb RAM (somewhat middle segment at the time). I remember trying to hear an mp3 on winamp and work on Microsoft Word at the same time. The words would appear a bit delayed after I typed them in, as long as the music was running. I guess that was the moment when it started being possible for the average user. On a second thought, CD playback was probably possible earlier because the load on the CPU is lower.


I was doing it from around 1988/89 with an external SCSI CD-ROM drive from a Mac. Sorry cannot remember the exact date but I know I got a CD-ROM almost as soon as they were available.

SCSI was extremely efficient so you could run audio and play in the background whilst using most development tools such as C++ compilers and database development environments like FoxBase+/Mac and 4th Dimension.


The question mentions "midi". A MIDI file is rather simple, as it is low bandwidth (small files). I see some other answers tackling that.

I see another answer mentions "Redbook" CD audio, which is very simple as far as CPU goes (CPU just sends instructions to the drive, and on some systems there was a cord going directly from the CD drive to the sound card, so the CPU didn't need to actively process the sound once it was started).

Just to provide some more information to fill in an additional part of the broader picture: I had a 486 DX 33 (i80486 processor, 33 Mhz), and it was able to play WAV files. However, WAV files took up an amount of disk space that was quite large for the amount of disk space available at the time. MP3 files represented a lossy way to play compressed files, so hard drive could easily fit an entire song. However, the files could "cut out" to silence during playback, using a dedicated player. The 486 DX 33 simply didn't handle the decompression enough to play that back in real time.

Back in the day, I was told that a 486 DX2 66 decode an MP3 file fast enough for it to play back in real time. Now, if you want to multitask, you may need an even faster system: presumably a faster 486 chip or a Pentium chip. The 486 DX4 chip was released in 1993 (per Wikipedia for "Indel DX4").

  • Sound card? My first CD-equipped machine didn't have a sound card, but did have a headphone socket on the CD-ROM drive. (A HP 9000 series, IIRC) Commented Feb 18, 2020 at 9:16
  • Oh yeah. That's right. Some CD-ROM drives had headphone jacks and music could be played that way too. So some drives supported Digital Audio Extraction (DAE) over the data port, which became more common as time went on, and some computers used a special audio cord to off-drive sound circuitry, and some drives supported a headphone jack (and a volume control knob on the drive itself). I don't think the answer's text is wrong or particularly lacking (as its main topic was more about the focus on MP3 data), @TobySpeight did bring up a correct and worthy supplemental point I hereby acknowledge
    – TOOGAM
    Commented Feb 18, 2020 at 15:51

The Motorola 68000 (first built in 1974) inside the TI-89 graphing calculator is supposed to be able to play music by repurposing the data transfer jack cable, although I never tried it personally. See examples of programs.

While I'm not certain it is possible to do something else while this runs, some of the programs listed say "able to play of the sound in background task".

  • True, except that the 68k wasn't introduced until 1979 - and the version it is used in the TI-89 dates from the late 1990s.
    – Raffzahn
    Commented Feb 16, 2020 at 16:34
  • Sure. I don't know enough about the hardware to know if the version they're running right now is compatible with the first version.
    – F.X.
    Commented Feb 18, 2020 at 21:20

Huh! No one mentioned musical line printers!

When I was a wee kid and dinosaurs still roamed the Earth, I was a Mainframe Operator and we made music by banging rocks together sending specially crafted ASCII art to line printers from mainframes:

Clickable YouTube Video link going to the Computer History museum below:

Claire de Lune on Line Printer

I distinctly remember the French Operator printing the ASCII art of "La Marseillaise" on any of our idle printers in the Machine Room (as a Data Centre was called back then) on "Le Quatorze Juillet" (14 July, Bastille Day) just to annoy us (and because he had nothing better to do on a public holiday in France)

Here is the blurb on how it worked

We even had ASCII Pr0n! Nah! Not Posting any links! Google it yourself!

  • 1
    I remember this from the University of New Hampshire computing center in 1969. It was definitely a thing.
    – cmm
    Commented Feb 20, 2020 at 15:31
  • 1
    I could have been the first-to-market with a pocket music player (the lPod?) except for the problems I ran into miniaturizing a barrel line printer.
    – dave
    Commented Feb 20, 2020 at 21:28
  • 1
    HIHI. Then the next entry should be programming a /360 to play Music on AM radio :) We did that with one very small 4004/45 still running at a remote office for local real time queries.
    – Raffzahn
    Commented Feb 20, 2020 at 21:48
  • Thanks guys! +1 to you all! @Raffzahn Does any recording survive???
    – Fabby
    Commented Feb 22, 2020 at 7:23
  • @Fabby There wasn't any recording. Just an AM radio next to the mainframe running certain loops.
    – Raffzahn
    Commented Feb 22, 2020 at 11:12

The IBM 1620 could play music by moving varying length numeric strings between locations in core memory. It generally played only a single line, so no harmony, but the overtone stack was great!

If you wanted to do some computation at the same time, no problem. Whip out your paper, pencil, and slide rule and have it while the computer played on. Circa 1968.

The PDP-6 at the MIT AI lab also had a music peripheral which consisted of connecting 6 filters to the low-order six bits of the accumulator lights on the console. Since the PDP-6 wasn't used for much at the time, you could fire off the PDP-6 to play a song and continue working on the PDP-10 in the same room. Multi-tasking on a physically distributed, multi-core, ASMP computing cluster. In 1971.

  • Wow! Never heard of that one! +1
    – Fabby
    Commented Feb 22, 2020 at 7:18

Supposedly, Strachey was the first at computer-generated music, on the Ferranti Mark 1, around 1951. The Mark I had a 'hoot' instruction to allow the programmer to alert the operator -- much like a Windows PC 'beep', I suppose -- and this was used as the sound source.

You can find an example on this BBC page.

(Grumpy-programmer aside: it's unfortunate how Turing gets higher billing than Strachey in this popular account.)

  • Hah! You found the oldest! +1
    – Fabby
    Commented Feb 22, 2020 at 7:22

I definitely remember a 486DX/33 being fast enough to play MOD files using MOD4WIN while working in Word.

It could handle some fairly high mixing settings (CD quality, with linear interpolation), so long as you didn't try to play a file with too many channels and had plenty of buffer space to cover busy points. In which case you'd get sound breaking up. If you disabled interpolation, I think it handled pretty-much anything you threw at it (which would have topped out at 32 channels, given the supported formats).

MIDI offloaded the actual synthesis to whatever was on your sound card, so anything that'd run Windows 3.x with sound support could play it while working.

Can't comment on compressed linear formats like MP3, as I didn't start using them until my Windows 98 or XP days.

You must log in to answer this question.

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