Apple

I've had a similar problem, and I think I have the solution. (Caution: the solution is "in the works", so not guaranteed to work.) I'll explain the situation, and then the solution I'm putting in place.

1. Object that performs the remoteIO is already working. Written in C++. Callback loop is pulling data sample-by-sample from cached buffers.
2. Remote I/O is triggered by user actions - start a oneshot, start a loop, start a loop running on a variable timer, stop.
3. Remote I/O callback loop looks for commands on every sample cycle, executes those commands, then gets on with its sample pull.
4. Commands go in a circular buffer managed by another tiny C++ class. From the outside any thread can check for command(s) present, queue up a command, remove a command.
5. For now the commands are just in values; that will probably change.
6. To get absolute minimum of thread protection, I just used a protected counter to coordinate.

Here's some code from the manager:

    // Declaration of counter used to determine if any commands are in the ring buffer.
    volatile int32_t hasCommand_;

void CommandMgr::writeCommand(int command) {
    *nextCommandIn_ = command;
    // Increment count of queued commands...
    OSAtomicIncrement32Barrier(&hasCommand_);
    // ...and increment the pointer to the next available buffer position.
    if (nextCommandIn_ == endBuffer_) {
        nextCommandIn_ = ringBuffer_;
    }
}

int CommandMgr::readCommand() {
    int result = 0;
    // If a command has been posted...
    if (hasCommand_ > 0) {
        // ...grab it, then bump the pointer to the next enqueued command...
        result = *nextCommandOut_;
        nextCommandOut_++;
        // ...and decrement the enqueued command count.
        OSAtomicDecrement32Barrier(&hasCommand_);
    }
    return result;
}

From: Morgan Packard <email@hidden>
To: email@hidden
Sent: Sat, March 26, 2011 3:47:04 PM
Subject: Re: best practices for sending data from UI to RemoteIO callback thread

Update on this. Calling performSelector:onThread:withObject:waitUntilDone pointing to my remoteIO thread doesn't seem to work. I understand that this technique relies on a thread's run loop. It would make sense that the remoteIO thread wouldn't have an associated run loop, and the target method would never be called.

-Morgan

On Sat, Mar 26, 2011 at 10:05 AM, Morgan Packard <email@hidden> wrote:

Hello,

I need to come up with a way for my audio thread to receive and defer "commands" sent by my UI. Specifically, I'm sending audio trigger messages from the UI side, and want to quantize those on the audio side. So the ui might generate, say, five varying trigger messages, which the audio thread will read and clear when it's ready.

My first, naive implementation went like this:

1) graphics thread adds "command" objects to an NSMutableSet
2) on the audio side, when a sequencer tick occurs, the audio thread reads the contents of the set, acts according to the command objects, and calls [NSMutableSet removeAllObjects].

My app has crashed a few times during manipulations of my NSMutableSet, and I suspect this is because of thread-safety issues. So I need to find a way to do this communication without, um, really bad violations of multithreading best-practices.

My first thought is to use performSelector:onThread:withObject:waitUntilDone:. Will this even work on the audio callback thread? If so, how do I get the NSThread which refers to the audio callback thread?

If the performSelector approach won't work, or isn't the best approach, what _is_ the best way to using the UI thread to "load up" the audio thread with a handful of tasks it needs to perform in the future?

******* note and apology for using objective-c in my render callback *******

I know it's been advised not to actually do audio synthesis on the RemoteIO callback thread, but I haven't figured out how to create an independent audio-generation thread which runs at high enough priority, so for now I'm sticking with generating audio in the RemoteIO callback. I'm also calling some objective-c code in my callback thread. Again, I know this goes against some of the advice I've been given here, but the app is running, audio is performing fine, with no glitches.

************************************************************************

thanks a bunch!

-Morgan

--
================================
Web:
http://www.morganpackard.com

Music/Art:
Latest album: Moment Again Elsewhere

iOS app Thicket available on iTunes store.

================================

--
================================

Web:

http://www.morganpackard.com

Music/Art:

Latest album: Moment Again Elsewhere

iOS app Thicket available on iTunes store.

================================