RE: scheduling a block from a render callback
RE: scheduling a block from a render callback
- Subject: RE: scheduling a block from a render callback
- From: Tim Dorcey <email@hidden>
- Date: Wed, 08 Jan 2014 10:49:50 -0800
Yes, you are probably right. When I originally started using this method, the local thread wake-ups were a LOT less common than incoming packets, so I did not want the overhead of adding another fd to every select. But, now that I am using with audio render callback the tradeoff may be different. I also tried using kqueue/kevent, which has the advantage that you can change the filter set while it is waiting on the kevent. However, that introduced some sporadic system crashes on the iPhone, and I never could figure out exactly what I was doing wrong. Tim From: Paul Davis [mailto:email@hidden] Sent: Wednesday, January 08, 2014 7:36 AM To: Tim Dorcey Cc: Lucas Ives; CoreAudio API Subject: Re: scheduling a block from a render callback On Wed, Jan 8, 2014 at 10:21 AM, Tim Dorcey <email@hidden> wrote: I put the data on a non-blocking FIFO queue, then send a 0 length UDP packet to a non-blocking socket I am waiting on with select(). It happens that I want to process the audio in my network I/O thread that is already waiting on the select() so this was convenient. I missed the rule about not using anything in the BSD layer, but I don't think this has caused any problems. i would probably avoid using UDP for this, because i think it has notably more internal (kernel) overhead than a POSIX FIFO ("pipe"), which you could add to the fd's used by select(2). but to each their own. really, mach ports are the lightest object for this on Darwin but apple is making it incrementally harder to use them. |
_______________________________________________
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