On Tue, February 23, 2016 9:35 am, Jonathan Brickman wrote: > What I want to do, is to use the resources I have to run multiple signal > generation and processing chains asynchronously, in parallel, and then > use the final audio-hardware-synchronized chain to resample them all > into one, perhaps using the Zita tools. I think you may be confusing two different concepts. Running in parallel running asynchronous processing You can run multiple independent synchronous processes in parallel, which is probably what you want. Using jack2 should allow that, but you have to check the connection graph to make sure it is happening. The original description you gave was not very detailed, are the Yoshimi instances just connected to the jack output and that is all? Is there any stage where both Yoshimi instances connect that would become the processing limit for the period? > use the final audio-hardware-synchronized chain to resample them all > into one, perhaps using the Zita tools. Resampling will always add additional latency. Having unsynchronized streams that have to be synchronized will always add additional latency. The zita-nj (network to jack) tools describe this very well in the man page excerpt below. I don't recall you relating what current latency setting you are using. If you are contemplating some complicated scheme which is going to add additional processing overhead and additional latency anyway, have you tried just increasing the buffer size? That is very simple to try and may be all you need. >From man zita-njbridge: When connecting two Jack systems with unsynchronised periods the minimum additional latency under worst case conditions is the sum of the two period times. Additional latency means any latency required to make the connection work without interruption. The round-trip latency from an ideal (zero excess latency) analog input on the sender to an ideal (idem) analog output on the receiver will be twice this value. Worst case conditions means that the both sender and receiver can run at arbitrary times within their respective periods. Zita-njbridge is designed to provide a defined and constant additional latency. The target value is the sum of the two periods, plus resampling delay, plus any extra buffering specified by the user. The actual latency will be this value plus the average network delay. -- Chris Caudle _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
