thank you for the help. I will read all of these things. I wish to use audio units and not queues because i anticipate latency being a priority for my app. Ideally, i have graphics objects that users can touch and it records what ever comes into the mic and when they touch up that object is a player of that sound file. So instantaneous (~128 frame buffer, perhaps) recording of pcm into .Caf/.wav files on demand from touch events.
On Mon, Jan 11, 2016 at 7:59 PM Ross Bencina <[email protected]> wrote: > Before I say anything else: it's true that you shouldn't do file i/o in > an audio thread (you shouldn't printf either), however check whether you > can achieve your goals with Audio Queue Services. My understanding is > that they take care of the queuing for you. > > On 12/01/2016 5:07 AM, Alexander Bollbach wrote: > > but essentially, the ring buffer functions as a method of temporarily > > holding the audio samples in memory from the rendering function in the > > realtime thread and than quickly reading those samples for some other > > purpose elsewhere? > > Yes. > > > using the timestamp to coordinate what exactly? > > You shouldn't need timestamps unless you're trying to synchronise with > something. > > > and > > wouldn't the ring buffer eat its tail eventually if the realtime > > callback was dumping sample data into the ring buffer faster than i > > could write it to disk? > > Yes, absolutely. Your disk thread needs to keep up. So long as you use a > big enough buffer you'll be fine. > > There are ways to detect overflow. > > > > I'm sorry but i find this just a bit difficult > > to negotiate in my head. > > As an alternative to a ring buffer you can use a linked chain of > write-behind buffers. I detail the approach in the paper linked here: > > http://www.rossbencina.com/code/interfacing-real-time-audio-and-file-io > > There's an animation of the reading-from-disk here: > > > http://www.rossbencina.com/static/writings/File_IO_ACMC2014_Bencina_Animation/filestreaming.htm > > writing-to-disk is kinda the opposite. > > There's also source code. > > Like Paul, I can't really comment further on the CoreAudio frameworks. I > prefer not to be locked to a single vendor. > > Cheers, > > Ross. >
_______________________________________________ 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]
