Weak TOSLINK (S/PDIF) output on recent MacBook Pros

I have been using a surround receiver with a 10m optical TOSLINK cable and a 2006 model MacBook Pro without any problems for years. With my early 2011 17" MacBook Pro however, as well as someone else's 13" MacBook Pro from the same era, the receiver started producing frequent bleeping sounds, subtle audio drop-outs, and sometimes even downright refusing to work until it was ‘rebooted’.

I suspected all kinds of causes, including the cable or degrading components in the receiver. However, with a totally different receiver and cable of similar length, occasional drop-outs were also noticeable although this receiver was more robust and able to resume fast enough that it wasn't too jarring. After some more tests it became obvious that the light output from the new MacBook Pro is simply weaker than on older models and many other recent devices with S/PDIF outputs. This is especially visible when simply looking at the end of the cable when first plugging it into the new MacBook Pro and then one of those other devices. The photo shows the output of the MacBook Pro (top) and of a TOSLink repeater (bottom) through identical cables.
The 10m cable causes a considerable attenuation of the signal no matter what (Wikipedia mentions 10m as the limit for cable length). But with the old MacBook Pro, apparently the end result was still strong enough. The data sheet for the detectors in the receiver states that they expect at least -24dBm. My guess is that with the new MacBook Pro + the long cable, the output drops slightly below this, which is why it is just on the edge between working and not working. Some solutions are: a TOSLINK repeater to drive the long cable, a more sensitive detector with coax connection to the receiver, or a USB sound card with a stronger optical output. I settled for a repeater for which I made a USB power cable for extra convenience.
Another example where newer is not always better…

OS X Lion: fixing stuck wallpaper

One of the many small annoying bugs in OS X 10.7 ‘Lion’ that seem of too low priority to get fixed by Apple is that sometimes the desktop wallpaper gets stuck at the same image. When changing it in System Preferences, everything indicates that it has changed but still the same image stays on the desktop. A reboot fixes this and for some people (I suppose especially those used to working with Windows) this seems a satisfactory solution, but the more seasoned Mac users frown upon rebooting for something as trivial as this.

There is a more elegant solution, being only restarting the process that is responsible for the desktop wallpaper. This process is the Dock, and it can be restarted by either typing “killall Dock” in a terminal, or by using Activity Monitor. Mind that this could have some side effects. Eventually you will probably end up rebooting anyway to get everything right, but this fix will work if for some reason you badly need to change the wallpaper.

OS X Lion: oplossing voor vastgelopen bureaubladafbeelding

Een van de vervelende kleine bugs in OS X 10.7 ‘Lion’ dat blijkbaar van te lage prioriteit is om door Apple opgelost te worden, is dat de bureaubladafbeelding soms blijft steken. Als deze veranderd wordt in de systeemvoorkeuren wijst alles erop dat er een andere afbeelding moet verschijnen, maar de oude blijft staan op het bureaublad. Het ganse systeem herstarten is een ‘oplossing’ maar voor wie dit niet gewend is vanuit Windows lijkt het overkill voor zo'n triviaal probleem.

Er is een elegantere oplossing, namelijk enkel het proces herstarten dat verantwoordelijk is voor de bureaubladafbeelding. Dit process is Dock, en het kan herstart worden door ofwel “killall Dock” te typen in een terminal, ofwel door Activiteitenweergave (Activity Monitor) te gebruiken. Het is mogelijk dat dit wat neveneffecten geeft, maar deze oplossing is bruikbaar als u om een of andere reden dringend de afbeelding wil veranderen.

Why do ‘Recent files’ show recently closed, not opened files?

Something that has annoyed me ever since the feature of “recently used files” has started to appear in software, is that it most often shows the wrong files. The easiest way for a programmer to implement this feature is to update the list of recent files whenever the user opens a file or saves a new file. This however does not make sense from a user point of view.
When I open a file, I have no desire to look it up in the list of recent files because the file is already open. Now if I work on this file during a long time and I open a lot of other files in the meantime, it will be pushed off the list of recent files. If I then close that file and think “ow, I should add one more thing” and I look in the “recent files” menu, the file is not there even though I worked on it only a few seconds ago!
When I wrote a simple HTML editor long ago I implemented the recent files menu such that it updated the list upon closing files. It was slightly more involved to get this working correctly, but it felt much more intuitive during use.
Edit 2012/05/18: the most recent versions of TextEdit in Mac OS X ‘Lion’ finally implement the ‘update-menu-upon-closing’. I hope this is a sign for things to come.

Waarom toont “recente bestanden” recent geopende i.p.v. gesloten bestanden?

Iets dat mij altijd gestoord heeft sinds het concept van “recent gebruikte bestanden” zijn intrede heeft gevonden in software, is dat het meestal de verkeerde bestanden toont. Voor een programmeur is het het makkelijkst om dit te implementeren door de lijst van recente bestanden te updaten elke keer de gebruiker een bestand opent of bewaart. Dat houdt echter geen steek vanuit het standpunt van de gebruiker.
Wanneer ik een bestand open heb ik geen nood aan het op te gaan zoeken in de lijst van recente bestanden aangezien het bestand al open staat. Stel nu dat ik gedurende lange tijd aan dat bestand werk en ik open intussen een hoop andere bestanden. Dan wordt dat eerste bestand uit de lijst geduwd. Als ik het dan sluit en denk “oei, ik moest nog iets toevoegen”, en ik kijk in de lijst van recente bestanden, dan staat het er niet tussen. Ik had er nochtans enkele seconden geleden nog aan gewerkt!
Toen ik lang geleden zelf een simpele HTML editor schreef, had ik het menu van recente bestanden zo geimplementeerd dat het bijgewerkt werd tijdens het sluiten van bestanden. Dit was iets ingewikkelder om correct te programmeren maar veel intuïtiever in het gebruik.
Update 20112/05/18: de meest recente versies van TextEdit in Mac OS X ‘Lion’ gebruiken eindelijk deze ‘update-bij-sluiten’. Ik hoop dat dit een teken aan de wand is.

Apple XCode 4.2 & SetFile command

A little-known fact is that Apple's XCode ships with two command-line utilities called GetFileInfo and SetFile. They allow to query and set various file attributes. Many of these are obsolete properties from the Classic Mac OS days but some are still relevant and pretty handy, like creation date (which cannot be changed with ‘touch’ AFAIK). An even lesser-known fact is that since OS X Lion, there was a bug in the SetFile command that caused it to set incorrect dates when used with the -d or -m arguments. The date was always set one hour before the specified date. This bug has been fixed in XCode 4.2.

Weinig mensen schijnen te weten dat Apple's XCode ook twee handige terminalcommando's installeert, namelijk GetFileInfo en SetFile. Deze laten toe om allerlei bestandsattributen op te vragen en te veranderen. Veel van deze attributen zijn relieken uit de tijd van Classic Mac OS, maar sommige zijn nog steeds relevant en nuttig, zoals de aanmaakdatum (die voor zover ik weet niet veranderd kan worden met ‘touch’). Nog minder bekend is dat sinds OS X ‘Lion’ er een bug zat in SetFile waardoor deze verkeerde datums instelde met de -d of -m opties. De datums die het bestand uiteindelijk kreeg waren altijd een uur vroeger dan gespecificeerd. Deze bug is opgelost in XCode 4.2.

Mac OS X Lion: showing file path in Spotlight / pad tonen in Spotlight

In versions prior to Mac OS X 10.7 “Lion”, when hovering over a file in Spotlight's results for a while, the file's path would appear. It could also be shown instantly by holding down the Command key. In Lion this has changed. The path will not appear no matter how long you hover over the file name. When holding down Command, a small pop-up at the bottom of the preview window will first show you where your search term matched (the file name or contents), and only ±four seconds later you will be shown the file path. That is pretty annoying if you quickly want to skim through the results for file paths!
Luckily someone on the Apple discussion forums has discovered that if you press Option (alt) together with Command, the file path will be shown instantly. Phew.

In versies van Mac OS X vóór 10.7 “Lion” kon het bestandspad zichtbaar gemaakt worden voor zoekresultaten in Spotlight door er ofwel een tijdje boven te blijven staan met de cursor, of Command in te duwen. Dit is veranderd in Lion: het pad zal niet verschijnen hoe lang u er ook op blijft staan. En als u Command induwt, wordt eerst getoond waar uw zoekterm overeenkwam (inhoud of bestandsnaam), en pas na een viertal seconden zal het pad tevoorschijn komen. Zeer vervelend als je snel de locaties van een hoop zoekresultaten wil weten.
Gelukkig heeft iemand op de Apple-discussiefora ontdekt dat als je Option (alt) tegelijk met Command induwt, het bestandspad ogenblikkelijk verschijnt. Oef.

Magic Mouse battery management

If you have a wireless Mighty Mouse and you're tired of the scroll ball getting clogged with gunk, you may consider buying a new fancy Magic Mouse. In many aspects it will be a step forward, except one.
The battery management of the Mighty Mouse was very good: it could run on a single cell, which means that when it told you its batteries were empty they were both guaranteed to be empty. The mouse would always keep drawing power from whatever battery still had some juice left. This made it possible to run for weeks even on a set of old worn-out rechargeable cells.
The battery management of the new Magic Mouse is not so mighty, nor is it magical. In fact it is absent. The people at Softpedia have already discovered this but they did not explain the root cause of the problem. I do not believe the Magic mouse draws much more current than the Mighty Mouse. The problem is that it treats the two cells in series like any primitive battery-powered device. It expects a total voltage of more than about 2 Volts. This means that if one battery is still going strong at 1.2V and the other one is dead at 0.8V, the mouse will shut off. The Mighty Mouse would still be going at that point because it would ignore the empty battery and draw current from the other one.
Especially with Apple now selling their own NiMH batteries and charger, their decision to drop the advanced battery management is puzzling. If there is any type of battery that benefits enormously from the separate treatment it is rechargeable ones. Contrary to alkaline batteries, NiMH batteries will maintain a quite steady voltage until they're empty, at which point they exhibit a very quick voltage drop. If one battery has less capacity than the other, this leaves no margin for the higher-capacity battery to further discharge because the series voltage plummets below the threshold. With alkalines the steadily dropping voltage provides more spring-action between the two cells.
I tried using 2300mAh cells in a Magic Mouse and they lasted less than two weeks of non-intensive usage. The scenario was as described above: at the end of the run one cell was empty and the other one still had quite a lot of juice left.
If you have multiple pairs of rechargeable batteries and a means to measure their actual capacity (e.g. with an advanced charger), try to match the batteries in pairs of equal capacity. They will give you more mileage. This does not only apply to the Magic Mouse but to any device that connects its cells in series (i.e. practically every device).
P.S.: Anyone who had a wireless Mighty Mouse might remember reading the mysterious notice “3Vdc Agency approvals inside” on its underside. Whatever it meant (I never found any ‘approvals’ while disassembling the mouse), I think the 3Vdc Agency would not approve of the Magic Mouse.

Mac OS X Lion: one month later

It has been about a month since I upgraded to Mac OS X “Lion”. In short, here's what I like and dislike so far:

Like:

1. ‘Natural scrolling’: it took surprisingly little time to get used to and after this short adaptation stage it proved so much more intuitive, even for the scroll wheel. And I don't even have any iOS device. I even tweaked my Linux environments to reverse their scrolling.
2. Applications and their open windows are remembered between logins. Especially handy for Terminal, which will even show previous output in gray.
3. The weird LCD backlight issue where the screen would sometimes light up again after dimming is fixed.
4. The acceleration curve of the mouse has changed to more resemble the acceleration under other operating systems. I believe the previous acceleration curve had remained unchanged since the introduction of the Macintosh in 1983, but I have always been annoyed by its extreme acceleration behaviour at very low cursor speeds. When going from OS X to Windows/Linux I never noticed anything unusual about the mouse, but when coming back the weird acceleration always took a while to get reaccustomed to.

Dislike:

1. My mouse cursor will often make unexpected jumps. Many other people have this issue and Apple is aware of it, but it still isn't fixed. It seems to happen mostly with third-party mice like my Razer Imperator. If you also experience this and want to have it fixed sooner, file a bug report at http://bugreport.apple.com and refer to bug ID #9701670.
2. The Finder does not play well with the remembered windows feature. Sometimes I see my previous windows vanishing into thin air immediately after logging in.
3. Instead of the LCD backlight issue, now the keyboard backlight will sometimes be blazing at full intensity when I return to my MacBook Pro after a while, even though I had turned it off.
4. There is often an annoying delay in ‘open/save file’ dialogs, with the hard drive rattling for reasons unknown.
5. There is still no good free Lion-compatible VNC server that I'm aware of (I'm waiting for an update to Vine VNC) and the built-in screen sharing is awful. It only supports bandwidth-gobbling lossless compression, it incorrectly assumes the command key is pressed at certain moments and worst of all, logging in requires a dozen attempts on average — unless you know the following trick. The issue is that when connecting, the login screen will only start to react to input after about five seconds and only during a random time period that ranges between zero and ± seven seconds. However, anything you do in those initial first five seconds will be buffered and executed. Therefore, click your login name as soon as it appears and immediately type your password + enter, even though you don't see anything happening. Just wait for ten seconds. If you're not too unlucky the connection will not freeze before your cached clicks and keystrokes have been executed, and you will be logged in. This still does not work every time but it increases your chances of getting in to something like 50%. Have fun playing login roulette!
6. The lack of scroll arrows makes it hard to impossible to advance a single line (or other unit) while scrolling.
7. Joesoft's ‘Hear’ still is not Lion-compatible, therefore I have to do with the standard sound quality of my headphones, which is not stellar despite them being from Sennheiser.
8. The XiphQT plugin has not been upgraded to 64-bit. No biggie since iTunes can be set to run in 32-bit, but I don't like to have to do tweaks like that.

Despite the ‘Dislike’ list being much longer than the ‘Like’ list the overall experience is still positive, but if there is no immediate reason for you to upgrade to Lion I would recommend waiting until it is a bit more mature and software developers have caught up.

If you're using Fink and can live with sticking with current release versions for a while, you can do an upgrade to Lion and keep using most of your existing Fink installation. I have found only few things that stopped working. Eventually you will need to reinstall everything from scratch however. When you're going to do that, be prepared for a disappointment because many packages are still not compatible.