vries1

Speaking about foibles, I see unusual CPU usage of Amarra 2.5.1 on my Mac mini / Mountain Lion. Whenever playback is halted (by the user, or because an album is finished), the CPU usage briefly goes down, from ~10% during playback, then sharply UP to 25-30% - and it stays at this elevated level. This is of course not a desirable state to leave the system in. Do other users see this as well? Is there a known configuration/setting to fix this?

Wwaldmanfan: for me, A+ 1.5.5 also stops exactly 3 s before the end of a singly-loaded track in the playlist. Mac mini server, Mountain Lion 10.8.4. The duration of 3 s is independent of the length of the track, or the format. When starting playback, the progress bar is partially filled with a grey background that seems to indicate the preloaded content (like in youtube or deezer) - but this grey background also stops just before the end of the progress bar. The missing 3 s effect (and the progress bar filling) is not present at all if the playlist contains multiple tracks.

Cemil - did you make sure that the USB DAC is not selected as output in the general System Preferences - Sound - Output? In a separate thread on iTunes 11.0.3/11.0.4 issues, it was mentioned that these iTunes versions caused difficulties to switch sample rate. The setup that seems to work for me is: I set sound output everywhere to internal EXCEPT in Amarra, where I force the output device to the USB DAC. With this setup, I can switch between 96 and 44.1 kHz without problems.

The problem might well be on the side of the Mac mini. If I run a Mac mini headless (without display attached), under Mountain Lion 10.8.4 I observe exactly the same problem. Amarra also has difficulties running in this configuration, see for example the following thread: http://www.computeraudiophile.com/f11-software/problem-amarra-2-5-a-16688/ It appears to be due to OS X 10.8 disabling or at least changing its use of the integrated GPU in absence of a physical display - but for screen sharing, one also need graphics processing power! Unfortunately, I have not found a software workaround other than going back to an older version of OS X. A hardware workaround consists in adding a dongle that simulates the presence of a monitor... Macminicolo Blog (Build a Dummy Dongle for a headless Mac mini). We could also keep fingers crossed and hope for Apple to fix the issue in OS X 10.9.

Cemil: I had similar problems with Amarra 2.5/2.5.1 running on a HEADLESS Mac mini (2010), under Mountain Lion 10.8.4. It only happens in iTunes integrated mode, controlled via Screen Sharing. I mention headless, because attaching a display to the server solves the looping/repeating issue... temporarily. Plug out the display and the problem returns. Searching on the web, I found that several other applications also have problems with headless operation under Mountain Lion. Some people attach a "monitor simulation dongle" to get OS X back to normal. I would not consider this a satisfactory solution but I have not found a software workaround other than operating under an OS X version pre-Mountain Lion.