Tuesday, May 21, 2013

Cord cutter

What do you buy a tech geek, who just buys gift-priced items throughout the year, for their Birthday? I just had a birthday, and I have no idea how my wife can find something that I don't already have.  It's not like I'm going to wait 2 months to buy a Roku or Shoes just because its temporally near my birthday. In contrast, a big gift wouldn't be a big surprise since everyone should coordinate something big (I've been burned by that, but that's another post).

This years gift was most fortunately by-chance. At a yard sale for some kids clothes, I stumbled upon a pair of Sennheiser HD-280 PRO Headphones. I had forgotten that I was on the lookout for new headphones, but seeing them there reminded me. The model number sounded really familiar too from my research. My mom taught me how to conduct myself at a yard sale, and jumping onto your phone to do research should be avoided (we wouldn't want to show our interest too much). A little flippant negotiation and I walked away with them for $3. They retailed for $150 when I was looking, but they seem to be down to $99 now.


Just getting a deal like that is like a present, but also getting nice replacement cans was the cherry on top. I used them for a little while in Neverwinter and with some FLAC files, then I quickly realized that I couldn't go back. They're great. There was one problem, the 1/8" plug was flakey. I tried putting a 1/4" collar around it, a complex set of rubber bands, and a few other things, but it was really sensitive to any movement. The solution was to replace the cord. The first option was to buy the replacement cord directly from Sennheiser for $30. That's not cheap, but given how little I paid for them, it's very reasonable. But what about when the cat chews on the cord? Or my daughter practices her scissor skills? I had just gone to Maker Faire, and wasn't going to let this opportunity to permanently fix them slip me by.


I modded them with a 1/8" jack, so that I could replace the cable in the future really easily. The Dr Dre Beats Headphones takes this approach and consequently has made a market for 1/8" to 1/8" cords just for headphones. I was little scared of taking them apart, doing some gutting out with a Dremil and performing some soldering. But, what the hell, they were only $3. Luckily the Sennheiser cord actually can detach and uses standard headers that I had laying around.


I had planned on ordering from Amazon and crossing my fingers that the jack would fit, but it occurred to me to check Radioshack and amazingly they had the part and it was in stock. That meant I could pick one up on my way home and get started right away. It came together really fast and I had it done just before 9pm. I used a closed-circuit panel mount plug, which sat really nicely after some plastics was drilled out and looked like it was originally there. I think they turned out really well. Future replacement cords can now just be bought from monoprice for a few bucks. I now also have the possibility of buying a cord with control buttons that I can use it with my phone.

I highly recommend attending Maker Faire, if there's one in your area. I left with some motivation and eventually granted some satisfaction from "making" something.

Call all the things!

At Gradle's core is a really nice set of Collection classes, which I wish were exposed on their own. The central feature is the idea around the all(Closure action) method, which says "run this Closure on every object", including ones added later. This is defined in DomainObjectCollection and it's leveraged by a few other methods. Specifically withType(Class<S> type, Closure configureClosure)and it's generalization matching(Closure spec). While they're very similar to Groovy's (and other languages) findAll or each, the extra temporal dimension makes it much more power for an API designer. Typically an API would provide a Collection which delegates to another collection while putting some triggers in place when something is added. With DomainObjectCollection, the user could create the collection and even prep it before passing it into an API call. It also allows multiple people to essentially register listeners, sorta like a property listener. In the following example, I configure other parts of the model based on what they all, for any value added or which will be added.

Loading ....
Another useful generic Collection is NamedDomainObjectCollection<T> (with its supporting implementations). These allow a collection to be built up with the assumption that each has a unique name, and it's really not too far from a Map with the key being the name. The magic comes from being able to build up an instance with methodMissing calls. The resulting calls look really slick and screams "DSL", I wish I had it for every Groovy DSL I write. As you can see in the next sample is a minimal way to create a list, which also has the ability to be configured for each item.
Loading ....

Tuesday, May 7, 2013

Another soul lost to Ubuntu sound issues

People have very selective memory (remembering the good things and forgetting the bad things). This is very true for the first few years of being a parent. It's also true for sound support in Ubuntu. Every time I upgrade my desktop's version of Ubuntu, I seem to be effected by some odd unknown problem with my Intel HDA sound. I say "seem" since I have selective memory about having trouble with it. But the last few days have brought all the horrible memories of scouring forums and bug tracking sites from years ago. Each of which gives "advice" that potential only cripples a system in other ways. For example, installing some PPA that hasn't been updated, or using OSS instead of ALSA, or ALSA instead of pulseaudio. Let me immediately say that I don't fall for them, I only browse them hoping that someone has commented on them with some real help. I found the best summary of this problem in an article titled "Top five wrong ways to fix your audio." The problems stem from Canonical having two audio troubleshooting pages. The first one, "SoundTroubleshooting" is outdated and downright dangerous, then it says to the use the second page. The second page, "DebuggingSoundProblems", has no more than "is the speaker plugged in."


My most recent upgrade to 13.04 manifested itself as ALSA being fine and pulseaudio silently coming up with no devices. This was good since it eliminated a slew of problems with the kernel, which is where 90% of ALSA really lives and consequently problems with how the modules are loaded. The way I knew this was running "aplay -L" to see which devices ALSA knew about. You can also run "alsamixer", but it won't give you device names. The best diagnostic tool I found for ALSA was speaker-test, which can target any of the multitude of drivers available. I quickly learned that some process has taken over the default sound device, via a "Resource is busy" message. I'm still not sure why "lsof /dev/snd/*" did tell me which process was grabbing the device, but a quick scan of "ps aux" showed the culprit as Pulseaudio. Odd, since Pulseaudio was exactly what I was trying to get working.

The breakthrough was realizing that the owner of that Pulseaudio was a user called speechd, which I assumed was some sound daemon, but proved to an artifact of the speech-dispatcher package. It turns out that this package starts up early on, starts its own Pulseaudio and never gives it up. It didn't take long to know that I didn't need a speech library for Lisp. Uninstalling the package did fail, but a manual userdel and it was cleanly gone. A nice side effect of uninstalling speech-dispatcher is that Ubuntu starts up twice as fast, and now safely shutdown (which it couldn't before).

I'd like to believe that my diagnostics process was this clean. Not even close. There were hours of trying new kernels, snd_intel_hda settings, and pulseaudio configurations. At this point I'm expecting to have another sound problem come November, but hopefully there's one less way it can fail without me knowing how to fix it.