[Samimy's] latest project is a little strange, but one man’s weird is another man’s wonderful so we’re not about to start criticizing his work. Nope, we’re here to praise the fact that his rotary phone turned reading light and audio amp is very well constructed.

He started by removing the phone housing. Those old enough to have used one of these devices will remember their bulk, and there’s a lot of unused space in both the handset and body housing. [Samimy] started by removing the speaker and microphone from the handset, and drilling a ring of holes to receive white LEDs. The circuit was wired so that lifting the handset turns on the lights.

But he didn’t stop there. A set of speakers and the audio amplifier circuitry from an old tape deck are also hiding inside the base of the phone. If you look closely in the image above you can see that he’s connected his cellphone and is listening to some tunes through the antique hardware. Take a gander at the video after the break to see construction and use of the project.

This proof-of-concept is just waiting for you to put it to good use. [Mike Tsao] wrote an Arduino sketch that lets him decode incoming audio data which could be used to program the device. He’s calling the project TribeDuino because it decodes an audio file which is actually the firmware update for a Korg Monotribe.

Earlier in the month [Mike] read our feature on a project that reverse engineered the audio-based firmware update for the Korg hardware. He wanted to see if he could write some code to read that file on his own hardware. All it took was an audio jack and two jumper wires to get the Arduino ready to receive the audio file. His firmware reads the Binary Frequency-Shift Keying encoded data as the audio is played, then echos a checksum to prove that it works.

This would be a fantastic addition to your own projects. Since the audio connection only needs to be mono, it only takes just one Arduino pin to add this jack (the other is a ground connection). Having just played around with alternative ways to push data to a microcontroller ourselves, we might give this a try when we have some free time.

[Phil] uses both his computer’s speakers and a set of headphones while working at his desk, but he was growing tired of constantly having to remove the headset from his sound card in order to insert the speaker plug. He’s been meaning to rig something up to make it easier to switch outputs, but never seemed to get around to it until he recently saw this LAN-enabled audio switcher we featured.

His USB-controlled switch features a single audio input and two audio outputs, which he mounted on a nicely done homemade double-sided PCB. The switch can be toggled using any terminal program, sending commands to the on-board ATtiny13A via an FT232R USB to serial UART chip.

The switch’s operation is really quite simple, merely requiring [Phil] to type in the desired audio channel into the terminal. The ATiny and a small relay do the rest, directing the audio to the proper output.

[Grissini] hasn’t had the best of luck when it comes to personal audio players. He estimates that he’s gone through about half a dozen iProducts/iKnockoffs over the years, which ultimately adds up to a lot of money poured right down the drain. Rather than lay down his cold hard cash for yet another music player that would succumb to a dead battery or cracked screen, [Grissini] decided that he would be better off if he built one himself.

His Orange mePod isn’t exactly the most attractive or sleekest music player out there, but [Grissini] says it works like a charm. An Arduino Uno powers the device, and he uses an Adafruit Wave Shield to handle the audio playback. Power is supplied via 4AA batteries which keep the tunes going for a reasonable amount of time, and afford him the ability to swap them out for recharging without much fuss.

The player was encased with some leftover cardboard and wrapped in bright orange duct tape, before being mounted on [Grissini’s] belt. He says he gets plenty of looks when he’s out and about, which you would expect from such a unique design.

Stick around to see a quick video of the audio player in action.

[Dino Segovis] wrote in to tell us about his “hack”, making an AB Audio Amplifier. The advantage of this particular amp is that the transistors never turn off, which would cause distortion. A full schematic is given in the article as well as a parts list. A complete “bill of materials” makes any circuit building project easier, especially for the beginner.

Although this is by no means a new circuit design, (a similar setup is used in car audio equipment) [Dino] does a great job of explaining how things work in the article itself and in the video after the break. He also gives some great tips about transferring your drawn circuit to a breadboard in a neat and organized way at around 5:00 in the video.

[Dino] tries to come up with something like this every week, so be sure to check back on his aptly-named site, Hackaweek.com for more fun stuff like this. Also, he mentions using the “free music archive” for his videos. This looks like a good resource for those that want to make other videos like this and need some music that legally doesn’t have to be paid for.

[Isaac] sent in his mashup build of a LED cube combined with a graphic EQ meter. The build is fairly simple and from the video we can tell that his build would be a great installation in a dubstep venue. While it’s not the 9x9x9 cube possible with some judicious coding we think it’s a very fitting display for the intended purpose.

Unlike purely analog audio visualizations using resistor and capacitor networks, the MSGEQ7 is a 7-band graphic equalizer IC that requires basically no support circuitry. The cube is powered from a few shift registers and takes up three pins on his Arduino.

Even with freaking enormous LED cubes, the resolution is still too low to do much of anything outside a game of Snake or Pong. Volumetric displays, while offering higher potential resolution, rely on a mechanism to spin the display around at a very high speed. [Issac]‘s build gets around that limitation by only needing a few LEDs every band of his EQ. It’s a very nice build that gives a purpose to all the LED cubes out there.

You can buy nice audio breakout equipment for your iPod if you don’t mind breaking the bank. This is partly because the demand is not incredibly high so commercial breakout hardware doesn’t benefit from volume discounts. But it’s also because Apple charges licensing fees for third-party accessories (often referred to as the “Apple Tax”). [Reed Ghazala] decided to side-step the whole situation by building his own accessory which he calls the iPad Audio Desk.

It all starts with a breakout board. The PodBreakout Mini provides an easy to solder interface for the iPad, and ensures that the repetitive act of plugging and unplugging the connection doesn’t break a solder connection. From there [Reed's] enclosure finishing skills take over. The shape and curve of the aluminum sheet give the look befitting an expensive tablet device. Along the back you can see the jacks for line-in, line-out, video, mic/guitar, and headphones that make the dock useful. It wouldn’t be hard to make one… but it might be hard to make one look this great. See for yourself after the break.

In our hands-on review of the Digilent chipKIT Uno32, we posed the question of what the lasting appeal might be for a 32-bit Arduino work-alike. We felt it needed some novel applications exploiting its special features…not just the same old Arduino sketches with MOAR BITS. After the fractal demo, we’ve hit upon something unique and fun…

So just what are the chipKIT’s unique features over a stock Arduino? Until the expected Ethernet shield ships this summer, a few ideas are on hold. Let’s see then…there’s no shortage of MIPS, of course…but there’s also heaps of RAM and flash storage. And with the latter, sampled audio came to mind. There are Arduino shields for just this sort of thing — the Adafruit Wave Shield turns up in many projects, using an SD card for sound storage — but if one’s needs are modest, the chipKIT’s PIC32 is perfectly capable of storing brief audio samples in its own flash program space, no cards, adapters or added expense required. We estimate the Max32 can hold nearly a full minute of voice-quality audio.

Playing with the idea, we found we could do one better. Actually, several better. A limitation of SD card-based players like the Wave Shield is that they can only play one sound at a time. Dealing with the FAT filesystem and buffering audio data off the card takes nearly everything the Arduino’s little ATmega chip can muster…polyphonic sound requires kludges. But our flash-resident audio samples on the chipKIT are trivial to access. With the fast 32-bit CPU, many samples can be processed simultaneously…and then, with gobs of RAM, time-based effects such as reverb can be added. And before we knew it, there was a toy synthesizer sitting on the table:

Having previously dabbled with the PIC32 using Microchip’s tools, we were surprised by the simplicity with which this went together. A few early rough spots aside, the chipKIT and MPIDE environment show major promise for being every bit as simple as Arduino. In fact, the whole build was completed faster than the documentation phase. And then a second surprise, even to us: everything in the parts list, aside from the chipKIT board itself, is common stuff that could be found at RadioShack. No funky special ICs, components or mail-order shields. Most of the “magic” is in software, thanks to this fast microcontroller.

Here’s a demonstration of the finished mini-synth in action:

Please excuse the demonstrator’s tragic lack of rhythm and coordination. This is why professional musicians get paid millions while amateurs lead sad lives as technology bloggers. Be thankful that we spared you the blooper reel.

Input is via five piezoelectric transducers (RadioShack #273-0073, $2.19 each) attached to analog inputs A0 through A4. We could have just used pushbuttons, sure, but we wanted something that could sense the pressure of each hit, and these were cheaper than force-sensitive resistors. Piezo sensors have a specific polarity, and the positive side (red wires) should connect to the analog inputs, and black to ground. There’s also a 2000 Ohm resistor added across each element:

Input for the reverb effect is straightforward. Two 10K potentiometers on analog inputs A6 and A7 (these are on the second row of analog inputs on the chipKIT Uno32, not present on Arduino). One controls the amplitude, the other controls the delay:

Finally, sound output uses high-speed PWM output on digital pin 3, passed through a simple low-pass filter to a headphone jack:

On our breadboard we’re using a handy little headphone breakout board from SparkFun, but one could just solder the appropriate wire leads onto a bare jack from “The Shack” (ugh). You may want to optionally add a 1 Meg pot just before the headphone jack. The circuit worked fine as-is with headphones or an amplified iPod speaker, but totally saturated our camera’s microphone input when fed directly.

This demo uses 16 KHz sound samples. As per Nyquist theory, the low-pass filter is then designed for an 8 KHz (-ish) cutoff frequency. For purely voice applications, half those rates should be sufficient (saving flash space and allowing longer samples), and the two resistor values should then be doubled.

And that’s it for parts. Can you believe it? On to the code…

To begin, we need something that can convert sound files into a format the C compiler can use. An ugly little UNIX command-line utility converts WAV files from a very specific format (8-bit mono, uncompressed) into C header files that can be #included by the MPIDE project. Arduino normally would use the PROGMEM directive to put these tables into the code flash space, but that’s not required here. Surprisingly, the much-loved Audacity program wouldn’t export 8-bit WAVs, but we found it possible to batch convert sounds using iTunes.

const signed char sample_drum[] = {
        0x02,0x03,0x01,0x00,0x00,0x00,0x00,0x01,
        0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x00,
        ...HUNDREDS OF LINES OF STUFF...
        0xff,0xff,0xff,0xfd,0xfd,0xff,0x00,0x00,
        0x00,0x00,0x00,0x00,0x02,0x00 };

We’ll spare you the horror of looking at that code or doing the conversion. You can download the complete set of project files here, and then adapt it to your own needs. The remainder of this article deals only with the MPIDE code.

But first, one fix is required: in our prior article, we encountered an issue with the chipKIT’s analog read speed, and a fix was discussed in the comments. This involves scrounging among the MPIDE source files for “wiring_analog.c” and changing a few lines. The old code resembles:

delayMicroseconds(99);
while ( ! mAD1GetIntFlag() ) { }
analogValue = ReadADC10(0);
mAD1ClearIntFlag();

This should be changed to:

delayMicroseconds(2);
mAD1ClearIntFlag();
while ( ! mAD1GetIntFlag() ) { }
analogValue = ReadADC10(0);

We’re told this change will be incorporated into later releases of the toolkit and this won’t be necessary for much longer. If you’re just ripping out the digital audio code from this project and ignoring this drum pad stuff, you can skip the change altogether.

And then there’s our sketch code:

// Mini sampling synthesizer for chipKIT Uno32.

#include "sounds.h"       // N_SAMPLES and data are here
#define PWM_PIN         3 // OC1 PWM output - don't change
#define SAMPLE_RATE 16000 // All samples fixed at 16 KHz
#define MAX_SOUNDS     10 // Polyphonic limit
#define MAX_ECHO     4000 // 1/4 sec fits in Uno32 RAM

short
  echo_data[MAX_ECHO]; // Circular buffer for echo

int
  echo_delay = 0, // Duration of echo effect
  echo_vol   = 0, // Echo effect volume (0-1023)
  echo_pos   = 0; // Current position in echo buffer
volatile int      // May change during interrupt:
  n_sounds   = 0; // Number of sounds currently playing

struct soundStruct {
  int sample; // Index of corresponding audio sample
  int pos;    // Current position within sample
  int vol;    // Playback volume, 0-1023
} sound[MAX_SOUNDS];

#define N_PADS N_SAMPLES // One pad for each sample

struct padStruct {
  short max;       // Max pressure during press (0-1023)
  short count;     // Timer for filtering out noise
  byte  triggered; // If set, currently reading a press
  short add;       // If >0, begin sound at next interrupt
} pad[N_PADS];

void setup()
{
  memset(pad, 0, sizeof(pad));    // Clear drum pad data
  memset(echo_data, 0, sizeof(echo_data)); // Clear echo
  pinMode(PWM_PIN, OUTPUT);     // Enable PWM output pin

  // Open Timer2, 1:1 w/256 tick interval (for 8-bit PWM)
  OpenTimer2(T2_ON | T2_PS_1_1,256);
  OpenOC1(OC_ON | OC_TIMER2_SRC | OC_PWM_FAULT_PIN_DISABLE,
    0,0);

  // Open Timer1 with interrupt for sample mixer (16 KHz)
  ConfigIntTimer1(T1_INT_ON | T1_INT_PRIOR_3);
  OpenTimer1(T1_ON | T1_PS_1_1, F_CPU / SAMPLE_RATE);

  delay(1);  // Slight delay avoids false trigger at start.
}

// Piezo transducers as input pads are fussy.
// To avoid false positives, a bit of hysteresis is used:
#define PRESS_MIN     20 // Must read at least this force
#define PRESS_COUNT    3 // for this many samples, then...
#define RELEASE_MAX    8 // Must read less than this force
#define RELEASE_COUNT 15 // for this many samples.
// Still imperfect; there are occasional double-triggerings
// and false triggers on adjacent pads.  Could be addressed
// with better mounting and isolation of pads and/or with
// improved input filtering in code or in hardware.

// The loop() function just reads pad and dial inputs; all
// audio work is done in the subsequent interrupt function.

void loop()
{
  int i, a;

  for(i = 0; i < N_PADS; i++) {  // Sample each pad...
    a = analogRead(i);

    if(pad[i].triggered) {    // Previously pressed?
      if(a <= RELEASE_MAX) {  // Yes, released now?
        if(++pad[i].count >= RELEASE_COUNT) {  // Really?
          // Sounds aren't added to play list here, just
          // flagged; they're added to the mix in the
          // interrupt.  This avoids a race condition
          // where this code may be trying to add a sound
          // while the interrupt is removing one.
          pad[i].add       = pad[i].max;
          pad[i].triggered = 0;
          pad[i].count     = 0;
        }
      } else {  // Still pressed...watch for new max
        if(a > pad[i].max) pad[i].max = a;
        pad[i].count = 0;  // Reset release counter
      }
    } else if(a >= PRESS_MIN) {  // Untriggered; new press?
      if(++pad[i].count >= PRESS_COUNT) {  // Really?
        pad[i].triggered = 1; // Flag to watch for release
        pad[i].count     = 0;
        pad[i].max       = a;
      }
    } else {  // Untriggered and below press threshold
      pad[i].count = 0;  // Clear press counter
    }
  }

  // Echo parameters come from potentiometers on A6 and A7
  echo_vol   = analogRead(6);
  echo_delay = map(analogRead(7), 0, 1023, 0, MAX_ECHO);
}

// This is the mixing/sample-playing interrupt,
// invoked at 16 KHz to match the audio sample rate.
// With guidance from Mark Sproul's PIC32 port of
// Brett Hagman's Tone library for Arduino.
extern "C"
{

void __ISR(_TIMER_1_VECTOR,ipl3) playSample(void)
{
  int i = 0, sum = 0;

  mT1ClearIntFlag();  // Clear interrupt flag

  while(i < n_sounds) {  // For each sound playing...
    // Waveform is cumulative, NOT averaged
    sum += (int)sample[sound[i].sample].data[sound[i].pos] *
      sound[i].vol;
    sound[i].pos++;  // Advance counter.  If end hit...
    if(sound[i].pos >= sample[sound[i].sample].size) {
      n_sounds--;  // Decrement number of sounds playing:
      // Move sound at end of list to the slot currently
      // occupied by the vacating sound (unless the same)
      if(i < n_sounds) {
        memcpy(&sound[i], &sound[n_sounds],
          sizeof(soundStruct));
        continue;  // Sound moved; dont advance index
      }
    }
    i++;
  }
  sum /= 1024;

  // Add in echo effect (if enabled) from circular buffer.
  // This takes place before audio level clipping so that
  // any clipping distortion won't be repeated in echo.
  if((echo_delay > 0) && (echo_vol > 0)) {
    sum += echo_data[echo_pos] * (echo_vol + 1) / 1024;
    echo_data[echo_pos] = sum;
    if(++echo_pos >= echo_delay) echo_pos = 0;
  }

  // Clip audio to 8-bit range.  This may cause distortion
  // when multiple sounds or echo exceed the 8-bit range.
  // Invoking the "quick & dirty" alibi again.
  if(sum < -128)     sum = -128;
  else if(sum > 127) sum =  127;

  SetDCOC1PWM(sum + 128);  // Set PWM output value 0-255

  // Check for any new sounds flagged by loop().
  // Done last because sounds finished above will
  // free up polyphonic slots.
  for(i = 0; i < N_PADS; i++) {
    if(pad[i].add) {
      if(n_sounds < MAX_SOUNDS) {
        sound[n_sounds].sample = i;
        sound[n_sounds].pos    = 0;
        sound[n_sounds].vol    = pad[i].add + 1;
        n_sounds++;
      }
      pad[i].add = 0;  // Clear flag even if not added
    }
  }
}

} // end extern "C"

Explanation:

The setup() function initializes two timers:

• Timer 2 and Output Compare 1 (hardware features of the PIC32 chip) are used for pulse width modulation (PWM). In conjunction with the filter previously described, this positions the speaker for each audio sample (Google for “PWM DAC” for explanations and examples). The PWM input clock is set to the chip’s full speed of 80 MHz, with an interval of 256 “ticks” (for 8-bit resolution), yielding a PWM waveform at 312,500 Hz. For this sort of DAC filtering it’s recommended that the PWM frequency be at least ten times the sample rate, so this is more than adequate for our needs. This is also why the code bypasses the native Arduino analogWrite() function for PWM, which operates on a much slower clock. Lastly, using Output Compare 1 dictates that we must use digital pin 3 for the audio output; this is one of the five native hardware PWM lines on this chip.
• Timer 1 operates at our audio sample frequency (16 KHz) and has an interrupt function attached. This function mixes audio samples and changes the PWM duty cycle of Timer2/OC1. The rates on both of these timers are set up once and never need to change, just the one duty cycle is varied.

This section of the code (and one line in the interrupt function) is admittedly not very Arduino-like, directly accessing hardware features in a non-portable manner. A more formal implementation would abstract these details into a library to which the novice programmer could just pass data. But for the sake of a simple, single-file demo, there it is, warts and all. In many ways, this is just a starting point to work from.

The loop() function reads the state of the piezo sensors and marks sounds to be played (received by the interrupt, later). There’s some crude debouncing of the piezo inputs…this really could use some more sophisticated filtering (which the PIC32 could easily handle), but it was skipped for brevity. The code generally detects varying pressure, but there’s still a fair bit of false triggering going on. In this function the reverb controls are also read: just two analogRead() calls, with the second one then mapped to the full length of the reverb buffer.

The interrupt handler is where all the fun stuff happens, and it’s surprisingly simple.

The extern “C” declaration makes the C++ compiler happy with the interrupt function declaration.

The program is designed for up to ten concurrent sounds, the details of which are held in the “sound” structure array (there’s more than enough CPU performance for greater polyphony, but it’s mostly just a matter that the input pads aren’t terribly practical for this). When a pad hit is sensed, a new item is added to this array (up to the maximum). Structure elements indicate which audio sample is used for this sound, the current playback position within the sample, and the volume level.

Audio samples are stored as signed values (rather than unsigned) because this makes them easier to mix (just add together) and easier to adjust gains (just multiply). Every opportunity is taken to use fixed-point math. From the prior fractal demo, we saw what a massive performance difference this can make — sometimes orders of magnitude. Most of our analog readings (returned as 10 bit integers from 0 to 1023) correspond to a gain (relative volume) value of 0.0 to 1.0 (or 0% to 100%). To perform this scaling in fixed-point units, add 1 to the reading, perform the multiplication (one instruction on the PIC32), then divide by 1024 (a simple shift operation, also one instruction). There’s no loss in accuracy vs. converting to floating-point; the source and destination values are going to be quantized anyway.

// Floating-point, slow:
// scale = float 0.0 to 1.0
out = (int)((float)in * scale);

// Fixed-point, crazy fast:
// scale = integer 0 to 1023
out = in * (scale + 1) / 1024;

Along these lines, note that where the audio samples are summed, this division is skipped until the end. This saves some cycles and the result works out the same. Algebraically speaking, (A/X)+(B/X)=(A+B)/X, and so forth. The interim 32-bit sum isn’t likely to overflow.

Fixed-point math happens again when applying reverb. The echo volume, in the integer variable echo_vol (10 bit again, from one of the analog knobs) is in the range 0 to 1023, corresponding to 0% (no reverb) to 100% (echo is as loud as the original sound). Reverb (in echo_data[] array) is a circular buffer — as sounds are played, the contents here (scaled by echo_vol) are first added to the output, then the result is placed back in the same position in the array and the position counter is incremented by one. When the end of the array is reached (or a shorter limit indicated by echo_delay) we “wrap around” back to the beginning.

The final resulting audio value is clipped to an 8-bit range. This may introduce clipping distortion when many loud sounds are used simultaneously. For brevity again, bells and whistles have been omitted, but courageous programmers could opt to add “soft clipping” here to limit such distortion. There’s ample CPU muscle.

The final 8-bit signed value is then transposed into the unsigned range and fed into the OC1 duty cycle for PWM output.

Lastly, the interrupt checks for any sounds that the loop() function flagged as being “hit,” and adds these to the concurrent play list. This flag-and-add behavior, rather than adding items directly in loop(), avoids a potentially nasty race condition whereby loop() could be in the midst of adding a sound just as the interrupt is removing others, throwing off the counter.

And that’s all there is to it. This demo only uses about one fourth of the storage on the Uno32, which itself has one fourth the capacity of the Max32…and we’ve yet to exploit any sort of compression. There could be some fun applications here, maybe adding better Super Mario sounds to toilets or voice prompts to other chipKIT projects (“Your door is ajar”). What other ideas could you see happening here?

When you think of Memorial Day weekend, what comes to mind? Well around here, all we can think about is this tank cum boombox that Instructable user [Elian_gonzalez] put together.

This build is actually the third version of his Music Tank, and it comes with all sorts of improvements over previous models. The tank is primarily constructed out of plywood, with cavernous compartments for holding all of its goodies. In its capacious body, the tank sports a 60 Watt stereo system that powers a pair of external speakers mounted on either side of the turret. The turret itself contains an air-powered cannon built from PVC tubing, which we imagine can be used to shoot a multitude of different projectiles.

While the concept itself is pretty cool, the tank happens to be nearly self-sustaining as well. The tank has a pretty deep battery well and uses a 50w home made solar panel to help keep things topped off while in use. [Elian] does not specify a total running time, but we imagine that it can go for hours on a nice, sunny day.

Keep reading to see a long video walkthrough of the Music Tank MK3 in action.

Hackaday reader [Sprite_tm] works in an office building that used to house several businesses, and as a remnant of the previous configuration, a doorbell sits in the hallway just outside his office. Several of his coworkers get a kick out of ringing the doorbell each time they enter the office. While not annoyed at the practice, he was getting tired of the same old “ding-dong” and decided to shake things up a bit.

He wanted to modify the doorbell to play random sounds when triggered, but he was pressed for time as it was March 31st, and he wanted to get it installed for April Fools’ Day. Without any real plan or bill of materials in mind, he pieced things together with whatever he happened to have sitting around.

He used a design borrowed from Elm-chan in order to play wav files from an SD card with an ATTiny85, and used an L293 H-Driver as an improvised sound amplifier. After sorting out some power-related problems, and configuring the circuit to be as stingy with its battery as he could, he declared the project complete. He originally aimed to deadbug everything on the metal sleeve of the SD card socket (which is awesome), but considering the size of the speaker and the battery he selected for the project, he ended up stuffing everything into a cardboard box.

We don’t care too much about how he packaged it, we just wanted to know what his co-workers thought of his doorbell augmentation. In the end, they loved it, but we imagine this doesn’t do anything to discourage any of them from hitting the doorbell multiple times a day.

Stick around to see a quick video of his doorbell hack in action.

The original iPod shuffle was a pretty small device, there’s no doubt about that. However, in the world of miniature audio players, [Chan] is no slouch either.

A few years ago, he set out to construct a micro audio player that used little more than a small microcontroller and a microSD memory card. He chose an ATinyX5 series microcontroller to run the show, utilizing its pair of PWM output pins to directly drive the speakers. Since there is no built-in amplifier, the audio volume is not loud, but it does sound reasonable if you use a set of high efficiency desktop speakers. He does mention that the sound can easily be amplified after passing the signal through a filter, so there is hope for those of you who like your music turned up to 11.

The only downside we can see is that the audio player can only process Wave files, but it’s hard to expect more from a DIY audio player smaller than a postage stamp. It would be great to see what sort of micro-handiwork [Chan] could perform if he were to update his design and build a full-functioning MP3 player based upon this project.

[Ed Zarick] is preparing his pinball project and wants to have authentic sound to go with the game play. The game is modeled after NBA Hangtime and in addition to music he also needs a wide range of sound effects to beef up the experience. To make this all happen at once he developed a set of Arduino WAV shields controlled by an Arduino Mega.

As you can see above, there are three ATmega328 chips which run the Arduino boot loader and each interface with one of the three green WAV shields. That set of chips listens for commands over and i2c protocol, and once they receive instructions they play can play the chosen file without affecting the other shields.

But to have the authentic sounds you first need to acquire the audio samples. [Ed] grabbed a ROM of the original video game and dumped all of the audio samples. From there it was a chore to listen to and catalog the sounds for SD card playback with the pinball version of the game. But it’s well worth the effort as the sound will end up tying the whole experience together.

[Andrew] recently offered to help out a friend who was looking to get her husband a SNES controller belt buckle. Rather than simply slap one together, he decided that it would be far cooler if the belt buckle played audio as well. He gutted a broken SNES controller, removing most everything inside, leaving just the buttons and a few wires.

To allow for the belt buckle to record sounds, he pulled apart a recordable balloon that would play a 10-second audio clip when shaken. He moved around a few wires, allowing for the audio board to be triggered by a button press rather than motion. Once that was done, he went about fitting it into the SNES controller, drilling speaker and microphone holes in the process. With the electronics components all set, he reassembled the controller shell and mounted it to an old belt buckle he had sitting around.

The final product looks extremely fun, and would make any die hard Nintendo fan’s day.

[Charlie X-Ray] is having some modern fun with the phone system by pulling dialed numbers from the audio track of YouTube videos (translated). The first step was to find a video where a telephone is being dialed and the sounds of the keypresses are audible. You can’t tell those tones apart, but a computer can. That’s because each number pressed generates a combination of two out of seven closely related frequencies. [Charlie] isolated the audio using Audacity, then wrote a python script to generate a spectrogram like the one above. By matching up the two dark nodes you can establish which two frequencies were played and decode the phone number being dialed. So how does this work again… find audio of a phone being dialed, decode the number.. profit?

Like most other DSLR cameras that feature video recording, the Canon T1i has a small built-in microphone with limited sound reproduction capabilities. [Robb] wanted better audio performance while taking video, but found the camera’s inability to use an external microphone to be a frustrating limitation. He decided to take matters into his own hands, and disassembled his camera in order to add an external microphone jack. The process is not overly complicated, as it requires little more than the installation of a switching microphone jack. You will however need to get your hands a bit dirty since it involves opening the camera, a bit of drilling, and some epoxy. Doing such things to your camera clearly voids the warranty, and with a $600 camera at stake, this hack is definitely not for the faint of heart. That said, if you desperately want to get better quality audio from your Canon T1i or 500d DSLR, be sure to check out his tutorial.