On Tue, 03.11.09 10:54, Daniel Mack (daniel at caiaq.de) wrote: > Hey, > > I'm currently hacking on modules for CoreAudio sink/sources and wonder > which way to go for the actual audio buffer transfer. > > CoreAudio is implemented in a asynchronous pull-io fashion, which means > that the user registers a callback (IOProc) to be called for the device > whenever there is a specified amount of data available and/or wanted, > respectively. That's all fairly straight forward. > > As the PA sinks/sources are set up to match the sample format used by > CoreAudio's IOProc, there is actually nothing more left to do inside > this callback than copying the buffers from one end to the other when > I'm called and then inform PA about new data arrival. > > Which API would cause as less overhead as possible? I didn't fully > understand the magic behind the PA RT threads yet, and I doubt I need that > at all as CoreAudio's IOProc is already called from a _very_ highly > priorized thread. This is actually similar to the JACK situation. On JACK too, the API allocates the thread and we need to make the best of it. In the Jack case we work around that by playing ping-pong between two RT threads: the one that is created by libjack and the one that is created by PA. This is actually really bad, since this means one additional context switch, and we really would prefer to do without it. The PA core actually does not require that it runs an RT thread that was created by itself, we are actually very flexible on this and could run fine with a foreign thread. However, what is important is that there is a way so that the PA core can wake up the RT thread at any time and cause it to execute code then. Unfortunately JACK currently does not allow that, the RT thread can only be woken up by the JACK server, not by our PA core. Now the question is: how much control does CoreAudio actually give you for that high prio thread? Is there any chance you can trigger from the PA main thread that some code is run inside the RT thread CoreAudio maintains? That means to things: firstly, there needs to be a way to wake up the RT thread from another thread, and secondly that some arbitrary code can be executed in the RT thread then. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4
