Dorian, contrairement à toi, je considère l'achat de nouveaux Mac Pro "tube" avec Pro Tools natif sur Thunderbolt pour remplacer deux stations PT HD TDM. Quand je ferai des tests, j'en reparlerai ici...
Pour ce qui est de 10.9, j'y suis "abonné" depuis le premier DP en juin. J'ai six ordis à l'UQAM qui roulent présentement en 10.9 GM (trois Mac mini, un iMac, un MBP et un MBP retina) et mon MBP personnel est aussi en 10.9 GM.
Il y a eu des changements au niveau de CoreAudio qui pourront avoir un impact suivant une combinaison précise de deux facteurs: le pilote pour une interface donnée et le logiciel audio qui parle à ce pilote. J'ai frappé le combo "parfait" avec Cubase/Nuendo et les interfaces Metric Halo.
En résumé, si le DAW et l'interface audio peuvent communiquer en mode "24 bit integer", le résultat sera du bruit blanc à la sortie de l'interface.
Cubase/Nuendo préfére en effet la communication "integer" avec l'interface (par exemple, 24 bit), mais si ce mode n'est pas activé/disponible dans le pilote, il n'y aura pas de problème, la communication se fera en 32 bit float. L'audio sera OK.
Par contre, le mode "24 bit integer" est disponible dans le pilote des Metric Halo, donc ça ne marche pas.
D'autre logiciel comme Pro Tools et Logic communiquent en 32 bit float avec l'interface, donc là non plus, pas de problème.
C'est pas un résumé parfait, mais ça donne une idée: il y a des combos pilote/DAW qui ne marcheront pas.
J'enchaîne avec mes échanges avec Metric Halo:
Daniel a écrit :I've been using 10.9 since the first DP in June. We're now at DP 8 and there's a lingering problem with the MIO driver.
Non-pro apps, like iTunes, VLC and others, have no problem. But pro-app, like Nuendo and Logic, exhibit serious playback problems.
With Nuendo 5.5 and 6, stereo playback produces short bursts of white noise. With Logic Pro X, stereo playback results in OK signal on the left, but continuous white noise on the right.
When playing back in Nuendo, the console reports this message 23 times a
second:
kernel[0]: performClientOutput returned e00002e8
I didn't raise the flag earlier, waiting for that "feature" to disappear in subsequent DP releases, but it looks like it's here to stay...
Metric Halo a écrit :Can you reproduce this problem with any other App besides Nuendo?
I don't have Nuendo here and I have not been able to reproduce this problem with any of the Apps I have tried.
The error that is being reported is:
kIOReturnOverrun
It is not returned by our driver; rather it is returned by the IOAudioFamily (which is the driver framework for audio drivers in Mac OS X). While I don't have access to the source code of the IOAudioFamily in 10.9, I do have access to the code for 10.8. While there may be (probably are) some changes, this code does not seem to change that much from OS release to release these days.
In the 10.8 code, the only place that return code is generated is when the driver has been set to non-mixable format. In 10.7, Apple disabled non-mixable format at the user level and this remained disabled in 10.8. I am not sure if they have made changes w.r.t. this in 10.9; it may be that they have re-enabled this -- I will investigate further.
The thing is that if we are operating on the non-mixable path and is not sending buffers of the proper size, it would seem that the host has selected the wrong format and is not handling the format correctly.
This may be a bug in Nuendo, so please also report this to Steinberg/Yamaha.
Again, if this can be reproduced in another app, this would be helpful in resolving the issue.
Daniel a écrit :> Can you reproduce this problem with any other App besides Nuendo?
Audirvana, when its "Integer Mode" option is selected.
> This may be a bug in Nuendo, so please also report this to Steinberg/Yamaha.
Hum... Reporting a bug to Steinberg about Nuendo is like putting a message in a bottle.
Metric Halo a écrit :It sounds like Apple may have re-enabled Integer Mode (non-mixable) in Mavericks, but it is not automatically switching back to mixable mode when the non-mixable app completes.
Perhaps the work-around from our side is to simply disable the driver's support for non-mixable for the moment; that might fix it. To be clear -- this would not be fixing a bug in the driver, rather it would be disabling a feature that would mask a bug in either CoreAudio or the hosts (not sure which).
In any case, I will give that a shot and post a driver for you to try out…
Daniel a écrit : What are "mixable" and "non-mixable" applications?
Metric Halo a écrit :I'll post a driver with the non-mixable stream formats disabled; let's see if that works.
> P.S. What are "mixable" and "non-mixable" applications?
There are mixable and non-mixable stream formats published by drivers. If an app wants to have full control over the outputs of the device, it puts the stream into a non-mixable format. That means that only that one app can send audio to the device, and it does not need to worry about audio from other apps being mixed in (e.g. system sounds, iTunes, etc.) -- the device becomes "non-mixable". In addition, the audio is streamed from the app to the driver in the physical format that is selected (rather than in floating point). So the App does not rely on the driver to convert from floating point (and mixing the audio) to the physical output format (generally 24-bit fixed point). From the perspective of an App like Audirvana, this is a good thing, but an app that is using the device in non-mixable (e.g. integer) mode needs to do things differently than when the app is using the device in mixable mode; if it doesn't then you will either get errors or noise at the output.
In previous OSes, as soon as an app released the device, it was set back to mixable mode. It seems like this may not be happening in Mavericks.