Very slow loading of organs

I am currently trying to set up a Hauptwerk installation without a monitor on a new Mac mini with 16 GB of RAM, running OS X 10.8.2. During the initial setup I connected a simple monitor and everything went just fine. After de-connecting the monitor, the loading of every organ takes a very long time - for example for the Cappel organ I now have to wait more than 9 minutes, whereas with a monitor connected to the Mac it takes only 10 to 20 seconds. After the organ is loaded into RAM, there is no noticeable delay while playing and also no glitches. But if I switch to a different organ and then back to the first organ, it again takes a very long time to load - so this is not caused by re-caching of the organ.

This Mac is only used for Hauptwerk, but when using a different application (for example viewing the user manual with Apple's Preview) I did not observe delays except those caused by screen sharing over WLAN. Copying a 3.5 GB file takes about 75 seconds, so the hard disk access times seem to be the same as before.

Has anybody else observed this strange behavior? My other Macs have a built-in monitor, so a cannot check this out with an operating system before Mountain Lion.

Hansmartin (in Hamburg).

[B. Milan]

Hello Hansmartin,

I do not know why not having a monitor connected might cause a recache, however if you can send us a diagnostic file the Hauptwerk log file will report the reason for the recache. Whether or not that relates to the monitor I don't know (I doubt it) most likely something else is happening.

What option in Hauptwerk are you using to load the organs from a switch?

With Brett's help, I was finally able to find a solution to this problem - actually two different solutions, one in software, one in hardware.

The problem is caused by the Apple window manager which temporaryly blocks the loading each time when the progress bar of the "Organ loading" dialog window is redrawn (and this happens often). Therefore it is sufficient to obscure the progress bar with a different window in order to avoid the redrawing. Since Hauptwerk likes to put its windows to the front, I wrote a little AppleScript which brings a big Finder window to the front every 3 seconds and made this script into a startup program. In order to not prevent the computer from shutting down, some more work had to be done, but it finally worked.

The hardware solution is much more reliable and performant. The trick is to make the Mac think that a monitor is connected. For this, only three 100 Ohm resistors are needed (33 Cents at my hardware shop) and a MiniDisplayport-to-VGA adapter cable (costs a little bit more when bought from Apple). The resistors are connected to the VGA jack as described in the following link: http://www.geeks3d.com/20091230/vga-hack-how-to-make-a-vga-dummy-plug/. It is then necessary to set the screen resolution manually (using Apple Remote Desktop aka Screen Sharing), since the computer assumes the lowest possible screen size (600x800), and this is not sufficient for most organs.

I am having this exact same problem on two Hauptwerk projects now. Both of the Apple Mac Mini's I used have the same specifications (because I bought them within 6 months of each other) and were purchased new through Apple. As described in the original post, whenever I plug in a monitor using the HDMI port, boot times for the E.M. Skinner organ (including initial boot time) is about 20-25 seconds. If I unplug the monitor, the boot time extends to 15-20 minutes!
Is there any other possible 'fixes' for this problem than the one listed? This seems a usable method to fix the problem but a very 'cobbled up' way to do it. Has any other progress been made on this problem?

[mdyde]

Has any other progress been made on this problem?

Hello Craig,

I don't think we've heard from any other people with any tips that I could share. (There haven't been any changes in Hauptwerk relating to it, since I would regard it as a peculiar bug in OS X, rather than anything in Hauptwerk.) My general suggestion would be to contact Apple for support, in the hopes that they might address it properly.

[mdyde]

P.S. Even if hiding the progress bar helped to work around the issue whilst loading the organ, and given that OS X is handling screen redraws very sluggishly when no monitor is attached, you might possibly still risk poor audio/MIDI performance when actually playing the organ, since the virtual console graphics would be updating as you play (for virtual keys, etc.).

Hauptwerk's graphics intentionally run in separate threads (with communication mechanisms so that the audio/MIDI engines should never be held up directly by the graphics), but if the fundamental is low-level hardware/driver latency (similar to DPC latency on PCs) then the performance consequences could be system-wide (i.e. holding up everything that's running on the computer).

Hence (unless Apple can provide a better solution) the hardware work-around might be the most effective option.

"HDMI dummy plugs* are available on EBay and I have found them the best solution (cheap, easy, permanent) for reliable operation of headless Mac minis - it is not a HW-specific problem.

Would the HDMI connection taking the audio with it be involved in this behaviour? (HW would then re-cache.......)

Kinda of a simplistic question, but can we assume those 3 resistors are acting as a (dummy) load for the video and audio circuits of the HDMI circuit? I use a Thunderbolt to VGA adapter with no seeming delay. No connection to the HDMI port on a MacMini

Rgds,
Ed

Kinda of a simplistic question, but can we assume those 3 resistors are acting as a (dummy) load for the video and audio circuits of the HDMI circuit? I use a Thunderbolt to VGA adapter with no seeming delay. No connection to the HDMI port on a MacMini

Sorry to have caused confusion. I did not mean to imply that a Mac with a connected monitor needs an HDMI dummy plug! If it ain't broken it don't need fixing - nothing to see here - move right along etc.

The problem arises only with a "headless" Mac - ie one with no monitor at all. If no monitor is detected OS X behaves oddly. This is a long-standing problem and nothing to do with HW. Since Apple have not fixed it in the last ten iterations of OS X I don't suppose they will now. There are various software fixes, for example installing remote desktop software that replaces the monitor drivers with custom video drivers, but these have their own compatibility problems and are frequently broken by OS X updates.

Cheapest and easiest is a hardware solution that fools the Mac into thinking there IS an attached monitor.

One approach is using an Apple DVI/Thunderbolt/ Displayport video to VGA cable and 3 resistors: a cheap solution if you have the Apple cable/adaptor hanging about and don't mind bodging some electronics. The resistors simulate a 75 ohm load on the VGA analogue RGB channels. (There is no audio on a VGA connector). The apple connector is an "intelligent" cable that is fooled by these into thinking there is a VGA montitor connected and provides a fake EDID (Extended Display Identification Data) over the digital video interface.

But apple video cables are fairly expensive, and a neater and cheaper alternative is an HDMI dummy plug. HDMI is a digital interface using a packet protocol. (There are no real audio or video circuits in HDMI, only virtual ones). HDMI dummy plugs use microcontrollers to provide a fake EDID over the HDMI protocol in the same way real HDMI monitors use their microcontrollers to provide a real EDID. Depending on the fake EDID they produce, HDMI dummy plugs offer different fake resolutions, so 4K resolution dummy plugs are different to 1080P plugs.

Does this help?

[mdyde]

Would the HDMI connection taking the audio with it be involved in this behaviour? (HW would then re-cache.......)

Hello murph,

The computer's video output (HDMI) shouldn't be relevant to audio output from Hauptwerk, or audio devices, or Hauptwerk caches (unless conceivably you were specifically using the computer screen's speakers as the means for listening to Hauptwerk, but that wouldn't be relevant to this thread anyway because in that case you wouldn't be using Hauptwerk without the screen attached).