Sunday, May 24, 2015

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.

Monday, February 02, 2015

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.

Friday, May 02, 2014

Pharo 3.0 Projects - JavaLoader and iTunes Parser

I've been inspired recently with the new release of Pharo 3.0. I updated my JavaLoader project and added a brand new project called iTunes Parser. The JavaLoader project is an old project that can load serialized java objects and Java classes. The iTunes Parser can load the xml iTunes library file. Check them out if you use Pharo 3.0 and give me any feedback.

Sunday, November 17, 2013

One Year Of Pomodoro








Monday, February 18, 2013

Java Reader Update


Friday, June 22, 2012

Pomodoro Technique

I was reading Robert Martin's excellent "Clean Coder" and he mentions a productivity tool called the "Pomodoro Technique". The premise is simple. Work for 25 minutes, then take a 5 minute break. During a 25 minute period (called a Pomodoro), you concentrate on one and only one task. If you are interrupted, you deal with it once the 25 minutes is up. Sounded simple and I was looking for a way to increase my productivity.

The first day that I tried it, I was enlightened and shocked. First, I was amazed how much progress I could make on a task in 25 minutes. I loved the 5 minute breaks for short walks. But, I was shocked how little productive time I got done in that first day. I only got through four Pomodoros. The rest of my day was meetings and helping my team mates. But, in that time, I got more accomplished than the previous day.

I kept doing my work for the rest week using this simple technique. I discovered that I loved working this way. First, it was an effective way to manage interruptions. Instead of addressing an interruption immediately, I would simply delay until the end of the current Pomodoro. After a few days, everyone got the swing of it and supported me. Another one was taking the break in the middle of a task that spanned multiple Pomodoros. At first, it was hard and wanted to keep on working. But, I decided to stick with the program. What I found was that a lot of times, just the 5 minutes to walk away when I came back, my work would take surprising turns. It forced me to evaluate where I wanted to go at the beginning of the next Pomodoro. By the end of the week, I was getting more work done, tracking better on my estimates, and felt better about the work I was getting done even the number of Pomodoros was low. I was marking more tasks off my to do list than ever before.

The next week I decided to read Pomodoro Technique Illustrated and the free ebook. And I made adjustments to how I was doing it based on what was in those books. When I got in the morning, I looked at my to do list and prioritized what I needed to get done that day. Next, I estimated how many Pomodoros it would take to complete the task. If the task was longer than 4 Pomodoros, I broke it up into smaller tasks. What I found out by doing this is that I could make head ways via 25 minute chunks on multiple projects. I could spend a Pomodoro on a bug as a break if I wanted to to help break up the monotony of a long task. I also noticed that I was getting more Pomodoros done because I wasn't jumping up at every interruption.

Every day I'm tweaking how I work within such a simple constraint of working for 25, break for 5. In conclusion, the Pomodoro Technique will forever be something that I do to track work. I've been amazed how much it has helped me thus far. I love that it's easy to track time on my projects, forces me to take mental breaks and exercise, breaks my flow in a good way, gives a graceful way to handle interruptions, allows me to reassess my work, and is simple. I've even started to using it on my spare time projects, so I can better allocate time to the things that matter to me. I've even playing around with the 30/30 off-shoot as well to handle free time and working on household chores. But, that is another blog post.

Wednesday, October 26, 2011

Lost two of my heros

This month I lost two of my heros: Steve Jobs and John McCarthy. As a child, I dreamed of being Steve Jobs. I admired him for what he accomplished and his impeccable showmanship. I learned so much from him and his vision. I'm sad that I will never be able to meet him.

When I got older and learned about how Xerox Parc and John Engelbart inspired the Mac, I found Lisp. My love affair with Lisp goes back to college when I didn't quite understand it, but thought it was strange yet elegant. The light eventually went on and the true power of macros and functional programming was eventually revealed. To this day, there is a source of amazement that comes with Lisp and I thank John McCarthy for that. I wish I could have met him as well.

I can't express how I much these men touched my life without ever meeting them. They both hit the ball so far out of the park that they will be revered for generations to come. The bar has been set and I plan on standing on their shoulders. Thank you.

Saturday, June 04, 2011

The days of templates are over

When I first started to work with web applications, it was just servlets and then came JSPs. At the time, I didn't like JSPs (and to this day I still don't). They seemed like a necessary evil that got the job done. The thing I found repulsive about them was the mix of server and client code together. The switching of contexts just made both look ugly and hard to maintain. But, it was easier than generating pages directly from servlets by hand. Of course, there were other solutions that I looked for, but nothing got away from the horrid markup. Then, I fell in love with Seaside which did away with markup and generated content through a custom DSL. It felt better to me and loved it until I realized that it was only for the developer, not the web page designer. It made their life harder. Now, we all know we should use minimal content and have CSS do the layout. But, in this modern world, you need folks who are experts at web page design. You can not and should not alienate them.

Fast forward to now. Currently, I've been using Javascript frameworks and working mainly from the front-end. The project I'm currently working on is pure HTML/Javascript/CSS for the front-end with RESTful calls to the backend. I must admit, I had my reservations about this arrangement, but after working with it; it is the right thing to do. No more ugly markup. The separation of concerns is well in place. And finally, the web designer is allowed to concentrate on making a rich user experience and the developer to concentrate on business logic. Perfect.

My feeling is that the days of template engines are over. It's a waste of time and all of them are a pain to debug. A pure Web 2.0 AJAX solution allows each to utilize their tools and do things separately. To me that is exciting and I will gladly leave ugly code behind.

App Dev Today


Monday, April 04, 2011

Easier Memory Release In Objective C with Blocks

I've been getting my head around Objective C recently and remembering all that is great about about manual memory management. I found myself repeating code that either a) autoreleased or b) released with try finally loops. The autorelease puts a drag on your pool so you want to use it sparingly (with APIs where you don't know who will be calling it) and it's mentioned in several places in the Apple documentation to favor "release" over "autorelease". So, that leaves me with option b in most of my code with a lot of boilerplate code. And I hate boilerplate code. Well, did some more reading and found out that blocks are a new thing in Objective C and I quickly whipped this up:
typedef void (^Monadic)(id value);
typedef id (^Niladic)();

-(void)use: (Niladic)calc during:(Monadic)monadic {
    id toUse = calc();
    @try {
    @finally {
        [toUse release];
Basically, it allows you to send in one block to get the allocated object and then use it in a try finally. It automatically cleans up after itself! I then decided to try it out on some code:
-(IBAction)calculateClicked:(id) sender {
     use: ^() { return [[Cents alloc] initWithString: [startView text]]; } 
     during: ^(id startAmount) {
          use: ^() { return [[Cents alloc] initWithString: [eachYearAmountView text]]; }
          during: ^(id eachYearAmount) {
               use: ^() { return [[NSDecimalNumber alloc] initWithString: [interestView text]]; }
               during: ^(id years) {
                   Cents *answer = [startAmount
                          atRetirementAdd: eachYearAmount 
                          earning: years 
                          for: [[yearsView text] intValue]];
                   [resultView setText: [answer description]];
               } ];
          } ];
     } ];
I think I made it too generic in that I now have to type "^() { return [blah blah blah]; } every time. I realized I could get rid of those blocks and just pass in the object I want to clean up. Remove Niladic block and take two looks like this:
typedef void (^Monadic)(id value);
-(void)use:(id)toUse during:(Monadic)monadic {
    @try {
    @finally {
        [toUse release];
And this is what it looks like when you use it:
-(IBAction)calculateClicked:(id) sender {
     use: [[Cents alloc] initWithString: [startView text]]
     during: ^(id startAmount) {
          use: [[Cents alloc] initWithString: [eachYearAmountView text]]
          during: ^(id eachYearAmount) {
               use: [[NSDecimalNumber alloc] initWithString: [interestView text]]
               during: ^(id years) {
                   Cents *answer = [startAmount
                          atRetirementAdd: eachYearAmount 
                          earning: years 
                          for: [[yearsView text] intValue]];
                   [resultView setText: [answer description]];
               } ];
          } ];
     } ];
As long as the Monadic blocks stay on the stack we don't need to do the copy autorelease business on block objects. I like this code better than nested try finally code because I'm not repeating the name of my variable to release in the clean up code. I'm still not 100% happy with the code, but I'll keep playing around with other things until then. I do like the fact that it is simple. Just something I wanted to share as I learn Objective C.

Friday, March 11, 2011

Singleton Pattern in Dojo

var makeSingleton = function (aClass) {
    aClass.singleton = function () {
        var localScope = arguments.callee;
        localScope.instance = localScope.instance || new aClass();
        return localScope.instance;
    return aClass;

When declaring my class in Dojo, I did the following:
Then, to use it:
var instance = myClass.singleton();

Saturday, January 22, 2011

Functional Programming In Python 2


Collaboration Not Pairing






Friday, January 21, 2011

Domain Driven Design Immersion






Sunday, August 29, 2010

Imitation and Repetition

I was recently reading Alice Cooper, Golf Monster: A Rock 'n' Roller's 12 Steps to Becoming a Golf Addict and had an epiphany. In one of the chapters Alice talks about the way to be great at anything. He explains one should mimic the greats by watching and then repeat what they do until it's natural. I immediately started to think about programming, of course. We all have programmers that we admire. For me, most of my admired heros are great writers. It's their advice that I adore. I soak their words in and then practice what they talk about. But, it's not the same as reading code. What Alice was talking about was studying what the greats do and repeating it until it's as natural as the way you breathe. Where can we find great code? I always felt my programming took a huge leap forward with Smalltalk. The reason I think that is now crystal clear: Smalltalk encourages you to read other people's code. All of the tools embrace reading code. If you don't know how to do something, you can search via the tools to find something similar and then repeat what they did. There is a plethora of patterns and good programming in any Smalltalk system. All of the GoF patterns came from Smalltalk originally.

That's fine and dandy, but what about Java, Python, Ruby, or other developers? It's just as easy as finding an open source framework you love and diving head first into the code. Study it, practice writing in that style, and repeat until it feels natural. Open source gives us opportunities that only Smalltalk and Lisp did in the past: a limitless supply of software to study in any language we choose. But, this begs the question: How do I know I'm studying good code? Alice touches on this in his book by saying that as you pass milestones in competence, you know what the next level looks like. Start with code that looks good to you now and keep practicing. For me, I strive for readability. How can I remove all noise until the code I write is nothing but the language of the problem I'm trying to solve. I'm always reading code to find new techniques for removing noise. I study code written in different languages and see how I can apply any new techniques in the language I am currently using. I've found a lot of gems by studying from functional programming and applying them to object-oriented languages.

This brings up another interesting observation. If it's good to read code and practice writing it, when should you use a new technique? For me, I always practice a new technique a lot before I apply it to production code. Normally, once a technique feels natural and I know it like the back of my hand. Most of the open source libraries I've written have been to explore an idea that I saw somewhere else to play around with it. There's nothing worse than not having mastery and immediately applying it because it was new at the time. Be patient. Read, code, repeat. Always be reading and practicing. It's the only way to get better.