There shouldn't be a reason for using a memcopy until you're actually moving data in/out of the hardware. The audio will travel from through the daemon without being copied. I would recommend using DMA to finally move the audio to the hardware, but that's a driver level detail. If you're having trouble moving the data to and from the daemon itself, the pulseaudio primitives provide ways of using zero-copy buffers to communicate with the daemon. The API is documented here: http://0pointer.de/lennart/projects/pulseaudio/doxygen/. More details on what you're having trouble with would prompt more useful help! Justin On 10/17/07, Deb Briggs <Deb.Briggs at palm.com> wrote: > > http://www.kernel.org/doc/ols/2007/ols2007v2-pages-145-150.pdf says that > local clients can exchange audio data with a local PulseAudio daemon through > shared memory IPC ? is there any example code that shows this? Asking > because we're seeing quite high CPU usage (30%+) when using memcpy in the > read callback that we install via pa_stream_set_read_callback. > > _______________________________________________ > pulseaudio-discuss mailing list > pulseaudio-discuss at mail.0pointer.de > https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20071018/b1b54be5/attachment.htm>
