Re: best way to divert callbacks to main thread from audio thread
Re: best way to divert callbacks to main thread from audio thread
- Subject: Re: best way to divert callbacks to main thread from audio thread
- From: Robert Bielik <email@hidden>
- Date: Mon, 03 Oct 2011 21:34:41 +0200
Rich E skrev 2011-10-03 21:20:
(Oops, for got to hit the 'Reply to all')
Thanks for the suggestions.
In our case, it's going to take a prettttty ugly circular buffer, since there is no hard limit to the amount of data passed to the callbacks. floats, triggers, arrays, and they all take a copy since the audio app running underneath our wrapper is going to do something else with that storage space as soon as it can.
Well, I have similar cases, lot of different sizes of objects (my buffer size is 64KB, which means I can have up to 64KB worth of data in the buffer tops), and it works pretty nicely. What kind of throughput are you looking at ? (bytes/sec)
I agree this is the ideal solution, but we can't really have a fixed size circular buffer, so then we need memory allocations again..
If you need allocations, it means the GUI doesn't keep up. And if so, there is NO technique that will solve the problem ;)
Regards,
/Rob
On Tue, Oct 4, 2011 at 6:08 AM, Robert Bielik <email@hidden <mailto:email@hidden>> wrote:
For this kind of purpose I'm using a FIFO (wrapped circular buffer) to store object references (think placement new), then extracting info in
the GUI thread. No lock on audio side, and next to zero execution time.
Regards,
/Rob
_________________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden <mailto:email@hidden>__)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden <mailto:email@hidden>
_______________________________________________
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