High sensitivity headphones are picky about amps

Recently I decided to upgrade a pair of long in the tooth Shure SE215 IEMs after one too many wonky cables and a disintegrating right ear piece (the drivers are working as well as ever). I settled on the Shure SE535, and even if the 4x price increase hasn’t made my music sound four times better, I’m happy with the purchase.

I was less thrilled to hear a soft hiss when I plugged them into my handy (and affordable) Audioengine D3 DAC/amplifier. Fearing it was a defective product, I sought to have it replaced, but could only get a refund due to a lack of stock. I next ordered the similarly priced Dragonfly Black, and much to my dismay this device exhibited exactly the same issue.

As it turns out, their low impedance (36 Ω) and very high sensitivity (119 dB SPL/mW) make the SE535 IEMs easy to drive and suitable for portable devices with low output at the cost of not meshing so well with amps designed for headphones with higher impedance and lower sensitivity. After doing some more research I ended up with the FiiO K3, which is almost (but not quite) silent with no audio playing, and still within my desired price range. Regrettably Schiit products are overpriced in Australia, so I had to rule them out.

TL;DR: your fancy new IEMs might not be suited to your amp. Do your research before you buy.

Ubuntu 16.04: heirloom-mailx is replaced by s-nail

As of Ubuntu 16.04, the heirloom-mailx package is a transitional package for s-nail.

Not realising this, I was having trouble with mailx not recognising the /etc/nail.rc file I’d copied from a working Ubuntu 15.10 server. As it turns out, the global config file path for s-nail is /etc/s-nail.rc. I found this out quickly by using strings to find the text '.rc' in the mailx binary: strings /usr/bin/mailx | grep '\.rc' (thanks to jpollard for this tip).

Beware of the MiniNT registry key

As of Windows 10 Version 1511, ReFS isn’t available by default as an option when formatting drives that aren’t part of a Storage Space. It’s easy, however, to enable this functionality by adding a DWORD named AllowRefsFormatOverNonmirrorVolume under the Registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\MiniNT (an example guide can be found here).

Unfortunately, the presence of MiniNT Registry key causes various Windows components to think they’re running in the Windows Preinstallation Environment. Significantly, the presence of the key breaks the Event Viewer – attempt to open any log and you’ll be greeted with the following very unhelpful error message:

Event Viewer cannot open the event log or custom view. Verify that Event Log service is running or query is too long. The request is not supported (50)

If this weren’t enough, apparently Windows PowerShell remoting will stop working, too.

TL;DR: Delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\MiniNT as soon as you’re done formatting your drive with ReFS.

RealPlayer/RealDownloader poses as Firefox running on 64-bit Linux and sends HEAD and GET requests

I recently noticed some strange HTTP logs where a resource would be requested twice with two different User-Agent headers. In one case, the first request suggested the client was running Chrome on Windows, while the second request indicated that it was coming from Firefox on Linux. This didn’t make a lot of sense, so I did some digging.

The culprit turns out to be RealPlayer (and previously RealDownloader, a separate application that now seems to be abandoned). RealPlayer places an overlay over supported browsers (Internet Explorer, Firefox and Chrome and possibly others) that allows the user to save videos from web pages. It doesn’t seem to be a browser plugin as such – it runs in its own process and sends HTTP requests independently of the browser.

RealPlayer browser overlay

The software just happens to set the User-Agent header to something like Firefox running on 64-bit Linux. I sacrificed a virtual machine and installed all manner of RealPlayer software to try and reproduce this behaviour, and the latest version sends requests like the following:

My browser’s actual User-Agent header is:

Based on this blog post and this Yahoo! Answers question, the following User-Agent header was used by an earlier version of the software:

The Gecko build date and Firefox version number (but not the ‘rv’ token!) have been bumped up, but everything else (including the weird trailing ‘Chrome’ identifier) are the same.

I bet somebody got a really nice bonus for that feature: The ‘Get Windows 10’ notification area icon

As the great Raymond Chen once wrote:

I often find myself saying, “I bet somebody got a really nice bonus for that feature.”

“That feature” is something aggressively user-hostile, like forcing a shortcut into the Quick Launch bar or the Favorites menu, like automatically turning on a taskbar toolbar, like adding an icon to the notification area that conveys no useful information but merely adds to the clutter, or (my favorite) like adding an extra item to the desktop context menu that takes several seconds to initialize and gives the user the ability to change some obscure feature of their video card.

The ‘Get Windows 10’ application that Microsoft deployed to Windows 7 and 8.1 machines earlier this year as a recommended – not even optional – update (KB3035583) sure fits this bill.

In short, every eligible Windows 7 and Windows 8.1 user ends up with this icon in their notification area: Get Windows 10 Icon

Apart from looking fairly ugly (that top edge in particular is a blurry mess), there’s no way to close it even temporarily, short of killing GWX.exe in the Task Manager – note also that no-one thought to give it a descriptive name; it’s just ‘GWX’.

I understand Microsoft’s desire to have users promptly upgrade to Windows 10 (even if I wish they would delay its release by a year or so), but this kind of approach just destroys goodwill.

Fixing error 0xC190010C when attempting to update the Windows 10 Technical Preview

My Hyper-V virtual machine running the Windows 10 Technical Preview kept displaying the error code 0xC190010C when I attempted to update to the latest build (from 9841 to 9860).

I was able to resolve this issue by clearing the Windows Update cache as described here. Briefly:

net stop wuauserv
rmdir /s %WinDir%\SoftwareDistribution
net start wuauserv

What's up with Office 2013's context menu and tooltip shadows?

Update (2015-04-22): Somewhat surprisingly, a recent Office 2013 patch appears to have fixed this issue.

Update (2015-03-04): Office 2016 fixes this.

Update (2014-10-03): Office 2013 running on the Windows 10 Technical Preview (build 9841) exhibits the same issue 🙁

At some point in the not-too-distant past, Office 2013 started rendering strange shadow artefacts in the four corners of all context menus and tooltips:

Screenshot of Word 2013 Context Menu Shadow Artefacts

This didn’t always happen, as a quick search for ‘Word 2013 screenshots’ will reveal lots of images of glitch-free floating windows. I’m too lazy to check, but I’ll hazard a guess that this started happening with Windows 8.1 or Windows 8.1 Update 1.

Being Office, they’ve re-implemented every GUI element themselves instead of letting the OS handle them. One can sympathise with this approach, but it’s important to get the little details right. A bit like how the IE team should finally spend the time to get their scrollbars right. Of course, it’s folly to ever expect UI consistency on Windows when even Microsoft can’t get it right.

A man can dream, though. A man can dream.

Code samples on GitHub

I’ve put the code samples featured on this blog over the years on GitHub: