I filed FB23427180 with the test code, trying to figure out why I can't get kAudioOutputUnitProperty_ChannelMap to work correctly.

Thanks, I filed FB23426784 requesting that flag be added.

Simple channel re-ordering is all I need, but I can't get kAudioOutputUnitProperty_ChannelMap to work correctly. If I pass { -1, -1 } as a map it mutes both channels, but any other map results in no change to the audio. I've also tried setting the map on kAudioUnitScope_Output and kAudioUnitScope_Input, with no difference. I'm attaching a small test program that generates noise to channel 0, but also sets a channel map that should reverse the L/R channels. It doesn't work, and I get noise on L. Maybe you can figure out what I'm doing wrong, or if there's a bug somewhere? catest.c.txt

The rough steps for getting the audio unit: AudioComponentDescription desc = { .componentType = kAudioUnitType_Output, .componentSubType = kAudioUnitSubType_HALOutput, .componentManufacturer = kAudioUnitManufacturer_Apple, }; AudioComponent comp = AudioComponentFindNext(NULL, &desc); AudioComponentInstance unit; AudioComponentInstanceNew(comp, &unit); AudioUnitSetProperty(unit, kAudioOutputUnitProperty_CurrentDevice, kAudioUnitScope_Global, 0, &adevid, sizeof(adevid)); And then setting the stream format and channel layout: AudioUnitSetProperty(unit, kAudioUnitProperty_StreamFormat, kAudioUnitScope_Input, 0, dev_desc, sizeof(*dev_desc)); AudioChannelLayout layout = { .mChannelLayoutTag = kAudioChannelLayoutTag_UseChannelBitmap, .mChannelBitmap = 0x3f, // typical value for 5.1 audio .mNumberChannelDescriptions = 0, }; AudioUnitSetProperty(unit, kAudioUnitProperty_AudioChannelLayout, kAudioUnitScope_Input, 0, &layout, sizeof(layout)); Setting the channel layout like this doesn't return any error codes, but seems to have no effect. For the map looking inverted, are you referring to kAudioOutputUnitProperty_ChannelMap? I've also tried that without success, although I can't remember exactly what the result was. I'll see if I can re-test it.

The issue is that we're running Windows applications, and so need to implement the FSCTL_DUPLICATE_EXTENTS_TO_FILE ioctl. Since file creation and the copy operation are separate, an application could create the destination file, possibly modify its attributes/add extended attributes/open additional handles to the file, and then clone the contents in. I don't think it would be possible to implement that with full fidelity on top of clonefile()--we would need to get the paths to the source/destination FD (not ideal when we already have open FDs), clonefile() to a temp location, set attributes to match as much as possible, then rename the file to the destination path. Fixing up open handles to the original destination file to point to the new one would also be difficult at best.

Thanks for the reply, that's interesting. I don't expect that would be a problem, 99+% of our use of this would be to copy an entire existing file into another existing file.