Getting a USB sound card configured for Raspberry Pi 2

I recently tried to get a USB sound card working on a Raspberry Pi 2. My motivation was to start working on audio applications like writing my own synth. It's something I've wanted to do for a long time, but some odd reason never got around to it. At first, I simply tried to output sound via the built-in sound card. This experiment was successful of course, but there was a lot of noise in the output. I tested using the SonicPi program that comes with the Pi.

My next experiment was to use a USB sound card that I had gotten for cheap. Apparently, these are hit and miss and if I were to do it over again, I would get one from Adafruit where they sell ones that have been tested for the Pi. Everything worked out so I lucked out, but the path to success was not obvious. For your information, I used the CMedia HS100 from NRGtech. I also used the latest version of Raspbian (Debian Wheezy) and updated my pi firmware with "sudo rpi-update" before I even started since most guides mentioned to do this for latency.

Before I begin, I was repeatedly given the ALSA (Advanced Linux Sournd Architecture) document. There's a lot of information in there. I hope to spend sometime read it more thoroughly, but when you're trying to get something simple working, it's like drinking from a fire hose.

1. Plugin the USB sound card.
2. Navigate to the Menu>Preferences>Audio Device Settings.
3. At the top of the dialog, there is a drop down for the sound card. Mine displayed "bcm2835 ALSA mixer) (Default)". Click it and you should see your new USB sound card. Again, mine displayed "USB PnP Sound Device (Alsa Mixer)".
4. Select the USB sound card.
5. Click "Make Default" button.
6. You can click "Select Controls..." which brings up a dialog for you to be able to select things it can use to change settings on your sound card. I selected everything.
7. Make sure volume is up and USB soundcard is connected to either headphones or speakers. To verify, my speaker setup, I used the built-in audio output first before connecting USB sound card.
8. Edit /etc/modprobe.d/alsa-base.conf with your favorite editor (sudo vi /etc/modprobe.d/alsa-base.conf). I strongly recommend making a backup of this file. You can also follow this from an Adafruit article as well.
9. Find the line "options snd-usb-audio index=-2" and change it to "options snd-usb-audio index=0".
10. Add another line below the edited line: "options snd_bcm2835 index=1"
11. Save the alsa-base.conf and reboot the pi (sudo reboot).
12. speaker-test -c2 -D hw:0,0. This should work. You will hear white noise from left to right on your speakers.
13. aplay -D hw:0,0 /usr/share/sounds/alsa/Front_Center.wav
14. Success? Or did you get "Channels count non available". If success, you can stop now and celebrate. Have some fun with SonicPi!
15. sudo aplay -D hw:0,0 /usr/share/sounds/alsa/Front_Center.wav
16. This probably worked. If so, the answer is simple. Edit the $HOME/.asoundrc (vi $/.asoundrc). Back up the original is again strongly recommended.
17. Clear the existing contents of the .asoundrc.
18. Add "defaults.ctl.card 0"
19. Add "defaults.pcm.card 0"
20. Add "defaults.pcm.device 0"
21. Save .asoundsrc. Try "aplay -D hw:0,0 /usr/share/sounds/alsa/Front_Center.wav" again.
22. Success? Excellent. Glad this guide can help. If you are still having issues: this article and this one too helped me figure out what was going.

I wrote this guide up mainly for myself so I don't forget it and to use again. Hope it helps you as well.

Why Smalltalk is the productivity king

I've been thinking about why I'm so much more productive in Smalltalk than any other language. The reason is because I'm curious if you could bring some of it to other languages. So, what makes Smalltalk so special?

• Incremental compilation. There is no cognitive drift. Compilation happens at the method level when one saves the code. It's automatically linked in and can be executed. Smalltalkers enjoy programming in the debugger and changing code in a running program. The concept of having to restart an entire application is foreign to a Smalltalker. The application is always alive and running. In other languages, you code while the application is not running. Programming a live application is an amazing experience. I'm shocked that it's hard to find a language that supports it. Java running the OSGi framework is the only example I can think of. But, one still has to compile a bundle (which is larger than a method).
• Stored application state. Smalltalkers call it the image. At any point in time, you can save the entire state of the application even with a debugger open. I've saved my image at the end of the day so that I could be at that exact moment the next morning. I've also used it to share a problem that I'm having with another developer so they can see the exact state. It takes less than a second to bring up an image. It has the current running state and compiled code. One never spends time waiting for compiles or applications to start up.
• Self contained. All of the source code is accessible inside the image. One can change any of it at any time. Every tool is written in Smalltalk. If one doesn't like how something works, one can change it. If one wants to add a feature, one is empowered to. Since everything is open, one can even change how the language works. It's programming without constraints. The original refactoring tools were written in Smalltalk.
• Freedom from files. Allows Smalltalk to store the code in its own database. The shackles of the file system makes compilation and version control trickier. Smalltalk can incrementally index code to make searches quick and efficient. The structure of the code is not forced to fit into the file system mold.

Now, the question one has to ask is why don't we have these features in languages that we use now? Personally, I would love to be able to keep my application running and change the code as it runs. I just want to end productivity lost to application restarts and compilations.