Jump to content

  • Log In with Google      Sign In   
  • Create Account


Sound wave generator - quick update

Posted by , 19 August 2012 - - - - - - · 736 views

I tried implementing the sound wave generation looping through hard-coded samples rather than algorithmically, but I have issues with the current implementation. The basic approach is straightforward but it took a couple of days to debug and the result still doesn't sound right. Apart from the output sounding lower quality, it is clearly out of tune. Not sure what is going on there - whether it's a discretisation thing, something with converting floats or merely another bug.

I decided to go with samples because it's very easy to add new wave forms. Create an array of floats for one wave period, plug it in, and you're done. AFAIK its the way sine waves were done in hardware due to how computationally expensive they are to calculate. Plus if I get around to adding normal non-looping sound files to this system it's done in the same way.

My gut feeling is that it is better to go back to implementing the core of this system as if it was on a hardware chip - using simple hard-coded algorithms, different for each tone, based on bit registers with different purpose per waveform - and then add a layer on top of that to convert instructions like "channel 1, triangle wave, 440Hz, half volume" into the right register values.

Eventually I want to play around with phase modulation, like what was used on the Yamaha chips used in Adlib sound cards or the Sega Genesis/Mega Drive, once I get my head around how the operators worked in hardware.

Buzzer Trio

Posted by , 09 August 2012 - - - - - - · 537 views

While implementing the tone generators in software I figured there's little reason not to simulate the actual clock speed of the hardware, at least to begin with. It means doing about six times as many calculations, averaging out the half a dozen sound values to the single one at 44100Hz rate sent to PortAudio. But when we're talking about a few odd million calculations per second with today's processors it won't hurt to add in a few million more. I really doubt any CPU bottlenecks of the future will be in the audio subsystem.

The three tone generators and noise generator are up and running. I'll need to play around more with the noise generator to learn how to properly use it, but the tone generators seem straightforward enough. I hand-coded in a short music demo to test how it sounds:

Three Square Wave Moonlight Sonata (no voltage drop-off):
Attached File  moonlight_10000.mp3 (1.07MB)
downloads: 105
(I'm going to have to find or figure out a good way to represent sound data as commands, as hard cording everything in a big ol' integer array isn't the best solution.)

I've been playing around with simple ways of moving the sound beyond pure square waves to give the sound a bit of a more hardware generated sounding feel. So far all I've tried is a simple voltage drop-off, a method suggested in the Sega emulator page from the last entry. In hardware, the voltage when held will drift back towards zero. If you're using a float based internal representation for your sound data, it's pretty simple to mock that up by storing the output and multiplying by a fraction close to one (0.99...) every cycle.

In terms of effect, the multiplier morphs the square waves more towards being sawtooth, affecting lower tones more than higher ones (they have longer wave periods so the voltage is held away longer). And it also dampens the overall volume too, more noticeable for the stronger values:

Three Square Wave Moonlight Sonata (0.999 multiplier per cycle):
Attached File  moonlight_09990.mp3 (1.04MB)
downloads: 110

Three Square Wave Moonlight Sonata (0.99 multiplier per cycle):
Attached File  moonlight_09900.mp3 (1.03MB)
downloads: 104

Three Square Wave Moonlight Sonata (0.9 multiplier per cycle):
Attached File  moonlight_09000.mp3 (1.03MB)
downloads: 102

I think I like the sound somwhere between three or four nines: it's close to the original but with some more interesting edge to it. But two nines has an interesting hardware sound too, and the crappy hardware sound of one nine is a nice effect.

SN76489 - Partying like its 1984

Posted by , 08 August 2012 - - - - - - · 789 views

For my little retro-sounding software audio system, the sound chip I'm looking for inspiration is the Texas Instruments SN76489. It, its variants and various clones were used in a lot of hardware from the eighties, like the Sega Master System and the Game Gear, the ColecoVision, the BBC Micro and the IBM PCJr/Tandy 1000. I'm not trying to directly emulate the SN76489 as closely as possible, but it will help to start by looking at how this chip works so I can make something that sound appropriately "retro"-ish.

The SN76489 features three mono square wave tone generators and one white noise/periodic noise generator with 4-bit (16) volume settings. I'm picking it as a starting point because it's one of the simpler sound chips in terms of operation yet can still make some nice tunes. Plus I grew up playing adventure games on a Tandy 1000 HX so I've got fond memories of those triple square wave tunes.

Useful SN76489 links:The links go into the details, but I'll sum up the basics:

The chip has eight internal setting registers which are set with byte sized commands to the input pins. The setting registers are:
  • 3 x 10-bit frequency settings for the square wave channels
  • 3-bit control mode for the noise channel ("periodic" or "white" noise with one of four speed settings)
  • 4 x 4-bit attenuation (volume) registers for the four channels

The chip gets a clock signal which it then turns into a internal clock. Different varieties of the chip allow different input clock frequencies - some allow up to 500kHz and divide by 2 for the internal clock, but the ones used in the consoles and computers appear to be the type that allow up to 4MHz and divide by 16. Either way ends up with an internal clock of up to 250kHz. But "up to" is the critical point - both the Sega and the Sierra links above say the standard operation was to tie the clock to the NTSC TV colour subcarrier frequency of 3.5795MHz, which gives an internal clock of 223.7kHz. The clock frequency directly affects the output frequencies so it will make a difference.

Each square wave tone channel has a 10-bit counter and an output bit. They work by resetting their counter to the value in their 10-bit frequency setting register until they reach zero, where they flip their output bit and reset their counter again.

The white noise generator uses a 15 or 16-bit linear feedback shift register, where the output is the bit that is shifted out the end and the input bit at the other end is determined by XORing two bits together (usually on the shift register). These are described in detail in the SMS Power page above if you want the details. It seems this is the part that varies the most between different chip designs, which might be important for anyone wants a characteristic noise generator for a specific system.

Each of these four channels outputs 0 or 1, which is set at their volume attenuation levels and combined in a mixer to get the analog output.

There are a lot of further subtleties that are better explained in the linked pages (especially the SMS Power one for Sega emulation), but the basics are fairly straightfoward: counters and shift registers.

  • Something I'll have to design for is the difference in clock speeds between actual hardware and software (semi-)emulation. My software is (probably) going to output audio at 40-44kHz, rather than the internal clock speed of 220-250kHz.
  • I'm going to have to think of a good way to get info from my program to the sound generation code. PortAudio's documentation says to avoid using mutexes in the callback function. I haven't done much tinkering with threads but I think as long as I keep the data transfer small and simple it will be fine, as the worst that could happen if the callback happens mid-data set is a brief sound spike.
  • Going to have to think of a way of encoding this type of audio in a more human understandable way than raw register settings, but that can wait until after I get the basics done.
  • I think the SN76489 was first used in 1979 or 1980 but it was used all throughout the 80s. I have to pick a year from somewhere in the decade. IBM PCJr and the Tandy 1000 came out in 1984, along with the garish 16 colour wonders of EGA - somewhere else I might be going.

Things that go beep

Posted by , 07 August 2012 - - - - - - · 429 views

I've been looking deeper into the audio system of Allegro 5, looking to see if I can do some tone generation for some retro-sounding bleeps. It turns out that Allegro 5's audio system isn't the best for this kind of thing.

Generating waveforms is simple enough. What I needed was a way to get my raw data from my own data structure to the OSes sound system. That's the sort thing a framework like Allegro 5 was designed to hide, not give easy access to. I also found the documentation on the audio system tends to gloss over the advanced features.

There is a callback function for Allegro's mixer data structure, which is designed for post-processing but can be used to set the values directly. And it works - mostly. The problem I found is that there is no way to manually set the update rate that the callback function is called. For my system and the audio settings I was trying (mono 16bit int sound) the function was fixed at 2048 samples per call. At a playback rate of 44100Hz, that's roughly a twentieth of a second per call which is a noticeable amount of lag. As far as I can tell from sifting through Allegro's source code there isn't any function calls or config settings to alter that short of putting them in the library myself. Which seems more trouble than it's worth given I'll probably break everything trying to make Allegro do more than it's supposed to do.

The better answer to me is to look for an audio library that is designed for this kind of thing. I'm trying out PortAudio. I haven't had much time with it yet, but so far I've got it running and outputing square wave beeps with a callback function running on my own set number of samples per call. 256 samples and the beeps sound instantaneous.

Given that's all I need PortAudio to do, I'm happy. The downside with a low-level library like PortAudio is that is all it does, so if I want to extend this to working on wave files I'll need to write my own loaders. Right now, I'd like to see how far I can go with old-style tone generation.

Additional: I've noticed these journals have tag functionality, which I'm currently not using. Is there a standard for how tags are used on GameDev.net?

Initial thoughts on Allegro 5

Posted by , 03 August 2012 - - - - - - · 711 views

I've got a simple "try all the basics" program running using Allegro 5 - bouncing bitmap with sound effects, playing music with an on-screen FPS counter using the font system and outputting keystrokes to the debug console. Nearly everything seems to be working fine. The only thing I haven't got working is tracker music formats, but since I'm not sure if I need that I should be fine with Ogg Vorbis. Bitmap-wise I know Allegro can read PNG files and that's all I need. From my brief look at Allegro 5 so far it seems like it will do everything I want it do. It's quite straightforward and simple enough to integrate with whatever I wish to do. I'll need to try it out on something proper to get a better feel of it of course, but so far it feels nice enough.

The only real hassle was getting all the libraries compiled and linked correctly, especially when I wanted to move from the standard defaults. Make sure there are separate debug and release libraries. Do you build for 32-bit only or also 64-bit, and maybe PowerPC if you're on a Mac? Do you go with dynamic linking, where you have to make sure you bundle all the libraries with your game and link them correctly, or static linking where you have to make sure the compiler links with the right libraries instead of defaulting to the dynamic ones.

It wasn't particularly difficult, but it did involve heaps of retries and fiddling with settings to get it done right. I must of recompiled and reinstalled the Allegro libraries about fifty times.

I'm going with static linking BTW, because I think I'm less likely to screw up including the right libraries at release time. I'm not sure about the 32-bit vs. 64-bit decision. I don't think it will make much difference to compile for both, but I also don't think it should make much difference for the sorts of 2D games I want to make to stick with 32-bit only. I had a check of all the games installed on the iMac I'm developing on and all the games appear to be 32-bit only (or older, PowerPC and/or 32-bit games; no 64-bit at all) so I assume there is some reason behind that.

September 2016 »

252627 28 2930 

Recent Entries

Recent Comments

Recent Entries

Recent Comments