Re: best practices for sending data from UI to RemoteIO callback thread
Re: best practices for sending data from UI to RemoteIO callback thread
- Subject: Re: best practices for sending data from UI to RemoteIO callback thread
- From: Morgan Packard <email@hidden>
- Date: Sat, 26 Mar 2011 15:25:38 -0600
So, after looking at your code, looks like the only piece data shared
by the producer and consumer is this hasCommand_ flag. Is it unsafe to
even increment and decrement a shared value (meaning a value that more
than one thread is writing to) without using these OSAtomicIncrement
functions? Perhaps that may be the reason for the mysterious failures
I get once in a blue moon.
-Morgan
On Sat, Mar 26, 2011 at 2:56 PM, wm schauweker <email@hidden> wrote:
>
> 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.
> ================================
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Coreaudio-api mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
--
================================
Web:
http://www.morganpackard.com
Music/Art:
Latest album: Moment Again Elsewhere
iOS app Thicket available on iTunes store.
================================
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden