Audio IC

[banedon]

Hi guys

Out of interest, what are people using for audio chips which are relatively easy to use and are readily available/modern? A lot of the ones I see in use are no longer produced and I'd prefer not going down that route. On top of that, they cannot function well at higher speed, although I could get around this by utilising a VIA I guess.

[Agumander]

How much of the lifting do you want it to do for audio? I just use a TLC7524 DAC and compute samples directly on a 6502

[banedon]

As much as possible . Really, my forte is definitely not audio, but I'd like to include something. If that has to be a beeper, than I'll do it, but I'd rather include something that can do a little more, doesn't require a vertical learning curve and something that I can get to grips programming-wise with when I have time. This might not even be the right place to ask to be fair, but you never know.

[drogon]

banedon wrote:

As much as possible . Really, my forte is definitely not audio, but I'd like to include something. If that has to be a beeper, than I'll do it, but I'd rather include something that can do a little more, doesn't require a vertical learning curve and something that I can get to grips programming-wise with when I have time. This might not even be the right place to ask to be fair, but you never know.

You can still get various old audio ICs if you look hard enough - the SN76489 as used in the BBC Micro is sometimes available on ebay...

And speaking of that, it's a pretty dumb chip - 3 channels of sound and one noise, but the boffins at Acorn devised a very clever way of making it seem much more clever by dynamically altering volume and pitch 100 times a second (via an interrupt) so using a simple tone generator can be quite rewarding - if you can write the code to match...

-Gordon

[banedon]

drogon wrote:

banedon wrote:

As much as possible . Really, my forte is definitely not audio, but I'd like to include something. If that has to be a beeper, than I'll do it, but I'd rather include something that can do a little more, doesn't require a vertical learning curve and something that I can get to grips programming-wise with when I have time. This might not even be the right place to ask to be fair, but you never know.

You can still get various old audio ICs if you look hard enough - the SN76489 as used in the BBC Micro is sometimes available on ebay...

And speaking of that, it's a pretty dumb chip - 3 channels of sound and one noise, but the boffins at Acorn devised a very clever way of making it seem much more clever by dynamically altering volume and pitch 100 times a second (via an interrupt) so using a simple tone generator can be quite rewarding - if you can write the code to match...

-Gordon

Yeah I was looking at that one. However, I was after something that's actually made today, or perhaps is done via microcontroller (video and audio are the two things I'll even consider using one in my SBCs). I was looking at the swinsid maybe, but am open to any other suggestions.

[AndrewP]

Agumander wrote:

How much of the lifting do you want it to do for audio? I just use a TLC7524 DAC and compute samples directly on a 6502

I'm going this route too but I'm putting the DAC behind a pair of 74HCT40105 16x4bit FIFOs (in parallel for 8bits). I then use a 32KHz clock divided-by-two to tick 8bits out of the FIFOs into the DAC at 16KHz.

Why?

Because it was fun. But to give a more useful (though still rationalised) answer. I don't need to service an interrupt happening 16000 times a second immediately. An interrupt happening at 2KHz id still a lot of time spent in interrupts but that's 8 times less than if I was driving the DAC directly. And it doesn't matter if I'm slightly late responding to that interrupt; there should still be 7 or 8 bytes in the FIFO.

Is this simple? Dunno. It adds at least two more ICs in terms of the '40105s and a 32Khz clock oscillator and '74 flip-flop to halve the clock speed and (in my case) one '04 hex inverter for some logic.

[barnacle]

Just a point to remember: the ear is extremely good at noticing both missing samples and irregularly timed samples (as well as all the other ills that audio sampling is heir to, like insufficient pre-sampling nyquist filtering) so you do need to ensure that you always have something in the buffer when the DAC comes calling!

Neil

[Proxy]

Some FIFO ICs like the IDT70x series have half full flags which you could use as the interrupt source in addition to the empty flag.
The idea being that when playing music (which can easily require more data than there is space in a FIFO) the half full flag will be used to get the CPU to top it off every now and then. Keeping the data stream consistent.
And for short sound effects or jingles the empty flag would be used to tell the CPU that it's done playing.

Hmm... now I'm wondering if you can combine both ideas.
Have 1 (or 2 for stereo) SN76489's behind their respective FIFO buffers, with the FIFOs automatically loading data into the sound chips at some set sampling rate (if they have data in them and are enabled through some sort of control register).
so it would work similar to the idea of having a DAC behind the FIFO but instead of feeding it raw sample data you instead load it with encoded commands for the SN76489 to set it's 4 voices and such.
either way you get the advantage of not having to manually babysit the chip and load it will commands in regular intervals, as the FIFO does that for you.

question just is, what's a good sampling rate? (ie speed at which data is loaded into a DAC/SN76489). 44.1kHz would be ideal, but that also means loading 43kB of data every second.

[barnacle]

Little bit of audio theory:

• The human ear is generally held to be capable of hearing from about 20Hz to 20kHz; less as adults grow older so probably under 16kHz, or worse, for most of us here.
• Understandable human speech is largely contained within the range 300-3400Hz, which have been the limiting factor for phone circuits for decades.
• For any frequency greater than 10kHz, it is impossible to hear the first or any subsequent harmonic. That means you can't tell the difference between a sine, square, or sawtooth wave at 10hKz or greater; they all sound the same because you can't hear the harmonics that differentiate them.
• The human ear has a dynamic range ability in excess of 160dB: from a mosquito a couple of feet away to a Vulcan Bomber a few tens of feet above you. To express that dynamic range would require around 32 bits (and a bloody good amplifier!).
• The human ear is very good at extracting information from signals which are very noisy. It can understand speech with signal-to-noise ratios of 10dB or less; it can extract tone information of less than one bit in a multibit sample.
• Nyquist requires that the signal being sampled must have *no* content above half the sample frequency; real world filters imply that in general the Nyquist limit is about 40-45% of the sampling frequency. Brick wall filtering is hard.
• Each bit in a linearly sampled signal corresponds to 6db of dynamic range, near enough.
• When recording or reproducing digital audio, the BBC considered (I was an engineer there for over thirty years, but I'm ten or more years out of date so this may no longer be current) that the sampled signal would contain 11dB or triangular quantisation noise, and 12dB overload headroom. Thus a 16-bit system would be considered to have a signal-to-noise ratio of (16 * 6) - 12 - 11 = 73dB, which is about the same as a good broadcast reel-to-reel tape machine. Note that a CD might have its input signal constrained or processed such that the headroom is not required, and so might gain up to 12dB in SNR.

Putting that lot together, in short, clearly understandable human speech can be easily transmitted with just eight bits at 8kHz sampling - 8kB/s data rate. A symphony orchestra requires at least sixteen bits and ideally 44.1kHz sampling (CD rates) - 88.2kB/s data rate per channel. So it really depends on what you're going to do with the audio. For 'reasonable' quality audio _provided_ that your input is correctly filtered, I would expect that say 10kHz bandwidth, sampled at 24kHz, is a reasonable starting point... but it's still a lot of data to be throwing around. A modern computer does it all by DMA transfers and that's probably the best way to do it here; the old Sound Blaster systems had a user defined buffer of a few tenths of a second long and triggered an interrupt halfway through.

Neil

[SimonJ5]

Another very 80s style chip is the AY-3-8910. http://www.microtan.ukpc.net/pageProducts.html (search for 'sound cards') contains two examples of connecting it to the 6502 bus.

Simon

[Proxy]

With a 65C02 or 816 running at 16MHz you can easily handle 8-10kB/s to some FIFO every now and then in software.
Even if each byte takes 100 cycles to transfer that would still work out to a bandwidth of 156.25kB/s.

So you could probably also do 44.1kHz, with enough time to add some overhead in form of having the audio data compressed and having the transfer code decompress it before sending it to the FIFO.

[gfoot]

If you have a VGA-capable video circuit then that is outputting about 30,000 scanlines per second - you could piggyback on that to grab one or two bytes during each blanking period for audio output. It's kind of life a free FIFO - the CPU can populate those bytes ahead of time once per frame and not have to worry about timing as much as the video circuit will then send them to the sound hardware at the right rate.

[barnacle]

That's exactly how the BBC (and other broadcasters) used to transmit sound to the transmitter circuits: Sound in Sync. It eventually used two bits per symbol to get sufficient data into the 4.7us sync pulse for NICAM stereo. They decided against using the picture blanking, other than the line sync.

Neil

[BigEd]

Perhaps see also the OPL chips, for example as mentioned in this thread:

• Basic Project Advice for 6502-based Synthesizer?

[gregorio]

I suggest one of the simulators of the SID6581 chip
armSID , avrSID etc.