[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: New here: question on MPNotifyQueue replacement David Duncan Thu Feb 04 12:00:04 2010

On Feb 4, 2010, at 9:16 AM, Howard Moon wrote:

> But your comment that CoreAudio runs in a real-time thread makes me wonder 
> about our AU implementation (a "wrapped" VST version).  That version makes 
> use of the file system's asynchronous read and write calls PBReadForkAsync 
> and PBWriteForkAsync, which were causing major problems in RTAS under 
> ProTools.  Those seem to be working fine in AU under Logic.  I'm worried that 
> perhaps these calls will cause a problem in Logic (or other VST or AU hosts) 
> now.
> One problem in ProTools is that it detects if "too much" time has gone by 
> without the processing returning, and it stops processing in that case.  
> Sometimes, the use of MPNotifyQueue was causing the thread to block.  But 
> calling either of those asynchronous read/write calls caused ProTools to fail 
> *every time*.  Since Logic has not (yet) shown a problem using those, I just 
> assumed that there is no problem.
> Do you know... should it be safe to use those calls from the real-time thread 
> in Logic?  Or should I implement the semaphore and lock-free circular fifo 
> queue that I've had to go to for RTAS?

In my understanding, async file system calls still have the possibility of 
taking a lock, but unlike their sync variants won't block to perform their 
functions. So I would have to say "I don't know" to be honest. This is probably 
something you should ask on the Core-Audio list, as I'm sure Bill or one of his 
engineers will have something to say about it :).
David Duncan
Apple DTS Animation and Printing

Do not post admin requests to the list. They will be ignored.
Mt-smp mailing list      ([EMAIL PROTECTED])
Help/Unsubscribe/Update your Subscription:

This email sent to [EMAIL PROTECTED]