[PATCH 3/3] winecoreaudio.drv: Use AUHAL API instead of AudioQueue

[Ken Thomases]

Hi,

I'm concerned about the use of the AudioConverter API within the capture callback (ca_capture_cb).  I have it embedded in my memory that it's not permitted to call a converter on the device thread.  I can't find a hard and fast declaration of that in the documentation, although Technical Note TN2091: Device input using the HAL Output Audio Unit does say this:

<https://developer.apple.com/library/mac/technotes/tn2091/_index.html>
"If sample rate conversion is needed, it can be accomplished by buffering the input and converting the data on a separate thread with another AudioConverter."

If what you're doing were allowed, it would seem they would have mentioned that and not suggested the use of "a separate thread".  It also seems that the HAL Output Audio Unit would just do this itself and not have the restriction on the sample rate in the first place.

I could have sworn that the API would actually generate errors if you tried to use it on the AUHAL's thread, but I may be thinking of the AUConverter audio unit, instead.  Ah, after more searching, I believe it was for the AUConverter audio unit.  There's an error, kAudioUnitErr_CannotDoInCurrentContext, that is generated if you try to use such a unit or if you try to make the AudioOutputUnit do the conversion itself.

Besides my specific recollection that sample rate conversion is not allowed, there's the general requirement to avoid slow operations in those callbacks.  The call to AudioConverterFillComplexBuffer() may be such a slow operation.  So could the calls to malloc() in your ca_capture_cb() and feed_cb().

Could you not move the sample rate conversion to the application thread, at the point where the application calls in to get the captured data (or metadata about it)?


In AudioClient_IsFormatSupported(), is it really the case that any format for which a stream description can be constructed is supported?  Is there a need to try setting the format on an AudioConverter to see if it will accept it?


There are still two mentions of AudioQueue in lines like:

    WARN("AudioQueue doesn't support per-channel volume control\n");


-Ken