Tuesday, September 30, 2014

Microsoft Windows 10 Was Unveiled Today

I have always been highly critical of the way Microsoft callously abandoned Windows 7 users by making the Windows 8 workflow completely schizophrenic and foreign feeling to desktop users, by focusing on the Metro/Modern look and feel, primarily aimed at touch screens and tablet users.

The desktop interface that we were all familiar with was almost an afterthought, rather like the DOS window in Windows. It's there if you really think you need it, but we think you're going to like Metro so bloody well, that you'll never go back. But we went back. Worse yet, Microsoft ripped out the "Start" button/menu. Experienced Windows users no longer had their "anchor" to use as the focal point for navigating around the desktop.

A fundamental rule in software development is you don't remove features; you deprecate them. Meaning that you can hide them, or make them configurable but turned off by default. But no, you're going to use Windows the way we say, and you're going to like it.

Some things improved with Windows 8.1 after the blow-back and slow uptake, which restored some of the worst inconveniences, but it still didn't cut it. Of course, we have gotten used to using Windows 8 over time, but many of us still miss some of the old features, and we still marvel at the screwy split personality of Windows 8.

So Windows 10 appears to have added back better desktop support, seamless transition between touch and desktop environments, and the ability to merge the two experiences without the schizophrenia that plagues Windows 8. I'm waiting to get my hands on an advance copy of Windows 10.

Sunday, April 6, 2014

WxService Update Available

WxMonitor ow4j141330

  • Improved the barometer tool tip to display a more conversational forecast status string.

Sunday, March 16, 2014

Android Audio Stutter -- Fixed!

Motorola DROID RAZR M
Not long ago I finally bit the bullet and replaced my old flip phone with a smart Android phone. I had several reasons: I had an increasing need to respond to people texting me, and the ability to check email and sync up work and personal calendars on one device was attractive too. I also figured I could take advantage of 32GB SD storage to put my entire music collection on the device, and have it with me always. Or so I thought.

Android audio playback was a disappointment. The audio quality was fine, if you can call stuttering, choppy audio fine. It would be playing along perfectly; I'd be enjoying the music, not thinking about the hardware, when all of a sudden it would stop for a half second or so. Very jarring -- disconcerting even! It doesn't take much to pull all of the enjoyment of music out of an experience when you get yanked back into reality every few minutes at random.

This pattern occurred with all three music apps I use: Amazon MP3, Pandora and Play Music. Choppy audio is usually due to multi-tasking other applications. I tried shutting down all the other running apps, trying to find the culprit. Unfortunately, even with all apps disabled, it kept happening. Then I stumbled upon the Power Control Widget. The Power Control Widget allows me to disable the sync feature (it turns off the periodic email, calendar and other data fetching functions). It appears the sync feature is what stutters the audio.

Android Power Control Widget
Left to Right: Wireless, Bluetooth, GPS, Sync, Screen Brightness

The sync feature may be a poorly written app, or maybe it really needs the hardware to run at a higher priority than keeping the audio buffers full, or feeding audio from the buffers into the D/A converters in real time. Whatever the reason, disabling sync seems to be the solution.

So, I set up a home screen with all of my audio apps, and with the Power Control Widget at the bottom. Now, when I go to play audio, I simply turn off sync. I admit, it's a pain to remember to do that (especially turning sync back on when I'm done listening), but it's better than the alternative. Maybe someday, the Android developers will fix this, but in the meantime I'll live with it as-is.

Thursday, February 20, 2014

WxService Update Available

WxService ow4j140220

  • Fixed a glitch in the total rain accumulation calculation. The reset time wasn't being calculated reliably, causing total accumulation to continue into the next day (or other configured recording interval).

Wednesday, February 19, 2014

WxService Update Available

WxService ow4j140219

  • Added support for WeatherBug publishing. To use the WeatherBug formatter, first register your station, and then follow the WxService setup instructions for expanding the zip file into your preferred location, and start WxMonitor. Switch to the Configuration tab and change weatherbug.formatter.password to the value you selected when you registered your Backyard weather station. Set weatherbug.formatter.station.id to the station ID that you received when you registered your station. Set weatherbug.formatter.station.number to the station number you received when you registered your station. Finally, add WeatherBug.formatter to wxservice.formatter.task.names (separated by semicolons), and click "Apply". The WeatherBug formatter transmits weather data to WeatherBug servers every five minutes (300000 msec) by default. You can change this by editing the weatherbug.formatter.interval property. One second is 1000 msec and one minute is 60000 msec.
  • Added code to explicitly set all temperature sensors to maximum resolution. This does not guarantee that any sensor will actually deliver higher resolution, and most 1-Wire devices are supposed to operate at maximum resolution by default. This is just an attempt to ensure the highest resolution.

Saturday, January 18, 2014

Is 16 Bits at 44.1 KHz Enough?

Is 16 bits at 44.1 Khz enough? Yes, if...

Spectral cleanup with dither
If you're just listening, and if the source material is properly dithered, and properly mastered, 16 bits at 44.1 KHz is good enough. Decades of double-blind testing have proved it time and again. But that's a big if.

There are a number of things that will affect the sound quality and the need for more bits and more samples. The modern CD loudness wars, which compress, limit and clip the audio into a quivering mass of Velveeta would get by with 8 bits and practically nobody would notice. A well-mastered and well-engineered CD at 16 bits and 44.1 KHz sample rate can sound fantastic. A poorly-mastered and poorly-engineered one will sound like crap.

Are there ever times when more than 16 bits and 44.1 KHz sampling would be better? Yes. In a recording environment, where the incoming live sound is unpredictable, it's better to leave some headroom for unexpected, accidental peaks. If you're using all 16 bits, and a louder peak comes along, it will overload the A/D converter. Eight additional bits provide 48 dB of additional headroom, which is itself more than the dynamic range of the vast majority of commercial CDs being sold today - especially the loudness war victims.

In addition, when mixing tracks, each additional track adds about 6 dB to the sum (assuming each track is mixed at full scale - a worst-case scenario). Mixing eight tracks will consume all 8 additional bits of headroom. To avoid overload, recording additional tracks means the level of all tracks will have to be attenuated in the mix. If they're 24 bit tracks, they can be turned down without any loss of resolution (they do have to be re-dithered however - in fact, audio should always be re-dithered when it is re-scaled - up or down).

For live recording and mixing, you can do better with 24 or even 32 bits (Audacity uses 32-bit floating point by default). But for commercial distribution via e.g., CD, 16 bits really is enough. Trust me on this.

So, what about sample rate? Well, that's much less important with modern oversampling sigma-delta A/D and D/A converters. Humans can hear at best, out to 20 KHz. Most of us are lucky if we can hear 15 or 16 KHz, although it really depends on how loud the signal is. I suspect more humans could hear 20 KHz if it's loud enough. For music, there just isn't much significant energy above 15 KHz. A sample rate of 44.1 KHz means that the digital recording system can accurately capture up to a maximum of 22.05 KHz: more than most anyone can possibly hear in a musical setting. The Nyquist Shannon sampling theorem tells us that we absolutely, positively need not sample more than twice the highest frequency of interest. This is not speculation; it is one of the most well-validated results in the field of information theory.

Aliasing
In order to prevent ultrasonic frequencies, above 22.05 KHz, from getting into the A/D converter and getting aliased back down into the audio frequencies, the input should ideally be filtered. As a practical matter, the filtering requirement on A/D converters is fairly weak, because most music doesn't contain a lot of energy at or above 20 KHz, and certainly not far enough above to be aliased down to frequencies that we hear readily. Still, most good A/D converters do provide high quality "brick wall" anti-aliasing filters. It is very difficult to build analog brick wall filters, but modern (i.e., since about 1995) oversampling sigma-delta converters can do this using digital filters with mathematical precision. They hypersample internally, but they output e.g., 44.1 KHz or whatever the desired sample rate is.

The filter function is different for D/A converters, but the requirements are about the same. The output filters are used to remove the ultrasonic sidebands that are generated by the sampling process. Although we can't hear them, those ultrasonic frequencies can wreak havoc with amplifiers and tweeters, and they need to be removed. It is probably sufficient to merely attenuate the ultrasonic sidebands with a softer roll-off that won't over stress downstream equipment. But modern (i.e., since about 1995) oversampling sigma-delta converters can provide digital "brick wall" reconstruction filters with mathematical precision.

Back when ADCs and DACs ran at the nominal sample rate, we had to filter using analog elliptical filters, and I could justify a bit of "slack" between the stop band and the sample frequency. It reduced the constraints on the analog filter, which were critical and hard to keep in spec. In those days, sample rates of 48 or 50 KHz were common. But for today's oversampling sigma-delta ADCs and DACs with their built-in digital filters, any sample rate above 44.1 KHz is simply an outdated concept.

Do we need to sample at 96 KHz? Certainly not! It doesn't make the filtering job any easier. All you're adding is more load on the CPU and wasting storage space. If you can't hear 20 KHz, you're never going to hear 48 KHz, or anything in between. And 192 KHz? That's four times higher than 44.1 KHz! If you can't hear 20 KHz, neither you or your dog are going to hear 96 KHz. Why on earth store all that inaudible chaff? It's processor abuse!

Monday, January 13, 2014

WxService Stops Responding After Approx 17 Hours

I noticed recently that WxService would stop responding after a WxMonitor client was connected for about 17 hours (or half that with two WxMonitor clients, etc.). It turns out that StAX XMLInputFactory cannot create more than 64000 readers in JDK 1.7.0_45. In other words, WxService can only respond to 64,000 update requests until the XML parser stops responding. At one request per second, a single WxMonitor makes about that many requests in about 17 hours. Fortunately, there is a work-around that should hold us until Oracle produces a fix for this problem.

Using Notepad or other simple text editor, create a a file containing the following text:
#Hack for JAXP00010001 error.
jdk.xml.entityExpansionLimit=0
and save it as C:Program Files/Java/jre7/lib/jaxp.properties (that is, place the file jaxp.properties in $JAVA_HOME/jre/lib).

I will publish an update when this is no longer a problem.

Update: The latest WxService includes a code change that uses a different thread pool implementation that seems more compatible with JAX-WS. By "more compatible", I mean "the one it uses internally by default". There were some features that I liked with the one I had been using, but locking up wasn't one of them, so there you go. If you're experiencing lockups, download the latest version