On Jan 31, 2016, at 3:18 PM, Charles Constant <[email protected]> wrote: > Thanks Brian. Lots of good advice there! > > > That's because some of your variables might be shared across all channels > > Thanks for the tip. I think what I need to do will be a good simpler. I'm > hoping I can send all the settings I need (static information about pan and > volume, pointers to my buffers, and information about where the buffers start > and end) bundled together in a struct like one can do in a render callback. If you're talking about AudioUnit development, then I think your design is already starting in the wrong direction. You don't send pointers to buffers around. The AudioUnit contains its own buffers. The C++ classes handle the data transfer between the AU host and the unit. Your AU code merely performs DSP on the objects' own buffers. Other information like pan and volume are set using AudioUnit parameters, so you don't need to send those around using your own mechanisms. There are standard ways to handle all of this in an AudioUnit, and you're best to just use the same techniques.
If you're talking about AudioUnit host development, then it seems like you should stick to rendering audio using C. There shouldn't be much need to send around pointers and other information unless you're mixing languages, and that's probably not a good idea. > > theoretically possible to write an AudioUnit in Objective C, but you'd need > > to be an expert on the language to avoid non-real-time aspects > > Hrm, the Obj-C route appeals to me quite, even if I finish by porting back to > C++. For starters, it's a good way to get familiar with Apple's AUBase.cpp > class. It also means I can get started straight away, rather then take a day > or two to figure to how to wrap C++ classes properly for Swift. Of course, if > I can't keep it running long enough to even test, there's no point. Writing an AudioUnit in ObjC is going to take a week or two, if not a month or two. Since you've already stated that you understand that Swift is not appropriate for rendering samples or rendering audio, then I don't understand why you'd spend a day or two wrapping C++ classes in Swift. Just spend the time you have learning enough C++ to make sense of the AU examples, and then insert your code in the appropriate C++ class. I think it would be useful to back up and examine what you're trying to accomplish by writing any audio code in Swift or pure C. Why can't you just write an AU in C++? Do you even need to write an AudioUnit? If all you need is an AU host, then why wrap any audio rendering in Swift? > > I suggest that you look for more AudioUnit hosting examples > > The basic hosting side isn't as wretched as I had expected. Yesterday I > ported Apple's "CocoaAUHost" sample code to Swift. But I still haven't done > anything that isn't streaming live to the mixer unit. I would like to find a > simple overview of how to offline render 3+ discrete channels of audio, but > I'm not sure there's much sample code out there that deals with something > that specific. I'd recommend that you keep your UI separate from your audio. That way, you can use Swift for the UI classes, and hopefully leverage some example code that send AU parameter changes without touching any actual audio samples. Then you can focus on plain C for the AU host audio rendering. My AudioUnit host applications are written in ObjC, with the AU callbacks designed to jump to plain C functions to process the audio. The AU setup code is ObjC, but it's not realtime. If you want to work with 3-channel or higher, I suggest studying the AUGraph API. That should teach you how to create a graph that has 3 channels. It should only take a day or two to build an AUGraph out of Apple's standard AudioUnits. You'll have to become familiar with all of the parameter settings needed to glue the individual units to each other in a graph. Brian _______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
