Hi, On Sunday 03 January 2010 20:19:10 Ken Restivo wrote: > The general approach I've seen in well-behaved apps is to do all the audio > processing in a separate thread, and stream the resulting 32-bit floats > into a shared circular buffer. The JACK callback then does little if > anything more than just reading floats out of the buffer, and incrementing > a counter or pointer (not protected by any mutex, the JACK callback thread > is the only thing that writes it, and all other threads only read it) to > show where it left off. Keeps the jack callback thread very light. But the main reason for the jack-thread is that processing there happens when jack needs it and with the priority jacks needs while all the extra threads (gui is one of them) have lower priority to not block the audio stuff. When you do the audio creation in another thread and only push it to the jack-threads ringbuffer, you have to make sure that buffer is always filled to not get gaps (actual xruns but without jack complaining, only audio missing). While this works when you "just" stream media from disk, this will not work with samplers/synths/effects as these react to external signals that come in in the same priority and should be processed as fast as possible instead of when the to-jack-ringbuffer actually reaches that data... If the sampler uses a separate thread (with lower priority), this would mean that the midi-event comes in and the according tone is just generated and appended to the ringbuffer. Some time in the future the ringbuffer would get sent to jack. But you actually want the jack-thread to only interpolate the events time inside its current audio-buffer and push the tone out as fast as possible. Otherwise there would be no valid reason to tune the audio-latency to low values for live-synths and effects... A well behaved jack app is not one that does almost nothing inside the jack- callback, its one that does what is necessary as fast as possible. That implies not using certain operations such as new/delete/free/malloc but allows for audio generation to be done inside the callback. And especially this allows for the callback to process the incoming audio and output it again in the very same call. (Which makes JackMix well-behaved:) Otherwise mixing and effects would all add a delay you don't want. Have fun, Arnold
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
