If you did, then you know that without purchasing some expensive hardware, your apple was limited to basically harmonic beeps and noise.
In 1994 I was a subscriber to Softdisk, which was a monthly disk publication for the Apple...by this time they also had a IIgs, Mac and PC edition...but they were still cranking out the original 8-bit issue and not only did I reorder the back issues from my early childhood that I'd lost (since at the time I still had my Laser 128 clone)...but took a new subscription because, hey, new software for the Apple was a great thing. The 8-bit version ended in August of 1995...having been in print for just about 15 years.
Issue 149 had something on it that really intrigued me....and in fact...I'd have to say if anything started my obsession with digital audio...it was this issue. Contained on that issue was a program called Sound Editor. I, out of curosity thinking it would allow you to create horrible digital bleeps and screeching, loaded it up. I was VERY surprised to see a waveform envelope window and was completely shocked when I heard a bell sound. Not a cheesy ding...but actual sampled audio...then I heard it play some sampled speech. It was utter amazement. I played with that program for probably 3 months splicing the small audio samples together in the limited ram size of the Apple.
Anyway, I know this isn't Goldwave related...but it's audio related and I wanted to share it with a bunch of like-minded indviduals. This program apparently uses an entirely software based DAC. I can't remember if someone asked about a software dac being done in the past on here (forum search turned up nothing)...but something like that strikes a bell...anyway....article and screenshots (and audio from emulated output) are below. This originally appeared in Softdisk #149...which was published around March of 1994. I was wayyy too young to understand the article then, but I do now. I hope you find it as intriguing as I did. I typed it up as it appeared on screen...typos and all.
by Michael Mahon
What's DAC? DAC is an acronym for Digital to Analog Converter. In this case, it refers to the process of taking a (digital) byte from memory and turning it in to a (analog) sound.
This article goes into a bit of the history of sound on the Apple and how my current SoftDAC came in to being.
Back in 1980, when I purchaed my first (16 kB, cassette) Apple ][+, I was intrigued by the possibility of using it's cassette input to digitize sound and it's speaker to play it back. In fact, I wrote mini-assembler routines to do just that, and an APPLESOFT program to use them to "read" hex dumps to me so I could check my typing against hex listings in magazines.
It worked but the results could hardly be confused with hi-fi! Both the input digitizer and the output device were limited to 1-bit resolution, essentially capturing and reproducing only the zero crossings of the input signal, so everything was infinitely clipped or "fuzzed" to the very edige of recgonition! A number of authors since have used this approach in programs like "Audex", "Doubletalk", and "Digicorder".
Apparently the Apple ][, for all it's wondrous capabilities, had serious limitations in recording and reproducing audio. These limits were repeatedly tested by the talented programmerrs like Paul Lutus, who in 1981 wrote electric Duet, which produced real two-voice, reedy music! A host of other programs used similar techniques during the 80's, but the fundamental (harmonic?) tyranny of square waves continued.
Then, in 1990, Scott Alfter wrote a little suite of programs to play Mac sound files on any Apple ][. I first ran across it on America OnLine, in a little demo called "Insert Disk." This was attributed to another author, but a perusal of the playback routine shows that it is, in fact, Alfter's.
Scott's SoftDAC was a new high watermark for audio reproduction on an 8-bit Apple. It played 11khz sampled sound files through the Apple speaker (or the cassette output) with tantalizing fidelity - not great, still gravelly, but much better than I had ever heard before. It inspried me to find out just how far you could go in making a vanilla Apple ][ sound like a IIgs or a mac WITHOUT adding hardware. This is the result.
HOW IT'S DONE
As I've suggested, the problem is that it takes several bits of precision in converting digital samples to sound to make "good" sound, but the natural audio output capability of the Apple speaker (prior to the IIgs) is only one bit. You can decide when to "toggle" the speaker, but that's it--the cone is either all the way in (or headed there) or all the way out (or headed there). Experiments have shown that hyman ear is essentially insensitive to the "polarity" of sound, so "in" and "out" can be interchanged in all the discussion that follows. (This is just as well, since we can't cntrol the polarity anyway!)
Paul Lutus (and others) found that greater resolution in speaker movement could be achieved by toggling the speaker (in and out) at a high frequency, and then varying the "duty cycle" of the square wave. Changing the duty cycle (the fraction of the time the speaker is commanded to be "in", say) of a high frequency square wave can be thought of as causing the spaeker cone to move to a prosition approximating the average value of the square wave, which is the duty cycle.
This allows us to generate multiple tones by changing the duty cycle at an audio rate to approximate the value of the sum of the two (or more) tones.
Scott Alfter refined this process sufficiently to produce 8 discrete posittions for the speaker cone, effectively implmenting a 3-bit digital-to-analog converter (DAC) by manipulating software timing loops. Brilliant!
Of course, there are some limitations. First, it's limited in it's sample rate to 11khz, or 93 clock cycles on an unaccelerated Apple ][. It could be slowed down, but the 11khz "carrier" frequency is already marginal and quite annoyingly audible. Second, with only 93 cycles to spend, it simulated only 3 bits of DAC resolution, so sounds are still somewhat "gritty." This is a result of "quantization noise": the difference between what the sound waveform value actually was and what is reproduced after only retaining only 3 bits of the sample.
In the case of a 3-bit DAC, the reproduction of each sample is off by an average of a little more than 6%--not bad, but unfortunately still quite audible.
(Postscript: In summer, 1992, Scott released a 4-bit version of his SoftDAC--half the noise of the 3-bit, but twice as noisy as this 5-bit)
HOW MANY BITS CAN DANCE ON THE CONE OF A SPEAKER?
After being inspried by Scott's code, I had to find out how many bits of precision could be achieved in a software DAC, at 11kHz, on a "stock" Apple ][. Until April, 1993, I thought the answer was 5 bits - but I was wrong! Greg Templeman took my statement as a challenge and proceeded to wirte a 6-bit DAC, again running at 11khz. A 5-bit DAC averages about 1.5% quantization noise, while a 6-bit DAC halves this, to 0.75% noise. Errors this small are practically inaudible against the background of a very loud 11 kHz carrierr tone, but more about that in a moment...
Before April of 1993, I thought 5 bits was the limit. My view was a single loop which, in just 93 machine cycles, had to:
1) Toggle the speaker to start,
2) Delay a number of cycles proportional to the valye of the sound sample.
3) Toggle the speaker again,
4) Delay a complementary number of cycles to maintain a constant carrier frequency,
5) Get the next sound sample (handling page crossings),
6) Test for the end of the sound, and
7) Use the sample to set up the next variable delays.
Doung all this within a single loop witha constant period of 93 cycles ruled out using more than 48 cycles for variable delay, while still allowing enough time to get the next sample, test for the end, and set up the delays.
What Greg saw that I didn't, was that for each sample, one of the variable delays is at least half of the maximum delay. So the split the loop in to two loops, putting some of the work of steps 5) through 7) in to the "long" delay! This allows for some of the delay period to be used for useful work, permitting a total variable of 64 cycles out of 93. The result is 6-bit resolution and higher volume (64/93 instead of 48/93 for my previous 5-bit DAC). Very clever! He has made the result available on America Online.
At this point, it seemed like the game was over--after all, with 93 cycles to divide up, and 1 cycle minimum resolution, 64 different duty cycles are the best we can hope for. But there was still one annoying problem for which had not been solved: the ear-numbing 11 khz "screech" of the carrier tone. The only way to eliminate it was to raise the carrier frequency above the range of audibility, say to 22khz, which would cut the timiing budget in half! That would require trading off resolution for greater speed...
SoftDAC: THE NEXT GENERATION
Hearing Greg's 6-bit DAC opened some doors for me. First, splitting the loop up got my gears turning about other ways to do useful work during delay periods. Second, starting from 6-bit resolution meant that doubling the carrier frequency would only require falling back to 5-bit resolution, which seemed like a sacrifice I could live with (an additional 0.75% quantization noise). Frankly, as Greg remarked via e-mail, in the presence of the 11khz carrier, it was difficult to hear the difference between 5- and 6-bit resolution.
This latest DAC is composed of 16 different pulse generators, each of which has the job of producing two identical pulses with "on" times varying from 6 to 37 machine cycles and with a constant period of 46 cycles. The total period of the two pulses is 92 cycles, the closest approximation to 11.025 kHz. (Actually, 11.092 kHz) At the end of each generator, it jumps to the generator needed for the next sound sample. It's only coincidental if it winds up "looping" by vectoring to itself!
The appropriate generator is selected by the most significant 4 bits of the sound sample, and the fifth-most significant bit is used to legthen the duty cycle by 1 cycle, if it is set. As a result, this software DAC, which I call DAC522, converts with a precision of 5bits and a "carrier" frequency of 22.05 kHz.
Dropping back to 5 bits to get rid of the 11 kHz carrier is, I think, a good tradeoff. Let your ears be the judge.
Since 16 different generators are used, each spreading the "work" differently among the speaker toggles, DAC522 is larger than previous DACs (1012 bytes). That's a problem for the sound editor, because memory is already tight, and it would be a shame to cut in to the mere 20 kB of space available for sampled sounds. the actual code for the generators is more structured than tight, so it would be possible to compress the code some by combining common "tails," but another avenue seemed even more promising.
I decided to put the 16 generators, which break naturally in to two halves, in to the 32 lines of hi-res page 1 which are hidden by the four lines of text in "mixed" mode! The initalzation and termination code and a 16-byte table fit nicely in to the leftover spaces, since each "bottom line" iis actually 48 bytes long. so in this version of SOUND.EDITOR, all of DAC522 is in the hi-res screen contained in the file SOUND.ED.OBJ, freeing page 3 for other uses.
The hi-res embedded form of DAC522 is a little awkward to use in oder programs (!), so I've included a single file, contiguous version, DAC522.8C, which is assembled to load at $8C00. The DAC is called by setting the start address at 6/7 and the end address at 8/9. The entry point is $2370 for the hi-res version, and $8C00 for the contiguous version. The source for DAC522 is available upon request.
(You may be interested to know that the source code for the duty cycle generators is itself generated by an Applesoft program, which does all the dirty work of counting cycles and scheduling the work between the timed events. This approach is a practical necessity for experimentation with such large chunks of timed code! Verification is done using an oscilloscope.)
I listen to my Apple //e through headphones, and the output of this software DAC sounds GREAT! You can also attach an external speaker, with or without amplification. If you feed the output in to your stereo, go easy with the volume control - you don't want to harm your stereo! You will want tto turn down the "treble" response of your amplifier to reduce the power level of the (inaudible) 22kHz carrier. Remember, tweeters can't handle overloads!
I ran the Apple II emulator's sound through VAC to capture the sound, which wasn't harmed any by the emulation. The sound sample below is basically a RAW recording in 44.1khz. Samples are played a couple times because I was watching the slight change in the waveform (which looks REALLY funky) with each play...showing just how complex (and simplistic) this process is. If you resample the files to 11.025 khz, you wind up with a cleaner looking (and sounding) waveform...even if it looks heavily stair-stepped. The editor, compared to others, is just entirely simplistic as you really only had keyboard input to work with and a maximum of about 1800ms.
Also, you might want to be careful with that audio file...due to the way the apple speaker works the file appears to have a VERY heavy offset and the "speaker" is being held in one extreme untill it starts playing. Just informing you. *new info: I've discovered that if you run a high pass of 30hz on these files, followed by a lowpass of 19khz, you filter out most of the offset and carrier noise and can get a somewhat better idea of the actual waveform output, although I highly suspect the harmonic doubling is from a sample-rate mismatch. I'm going to contact the emulator author to find out what sampling rate it outputs.*