<html dir="ltr"><head></head><body style="text-align:left; direction:ltr;"><div>Yes, same idea rolled into my application. That's why I was hoping the zita bridges would work well. I'm still troubleshooting the glitching with zita. Maybe it just on my test machine. I may end up having to look at the source code to understand what the various command flags actually do, and what the extra third number is on the verbose stats. printout.</div><div><br></div><div>Audiorack was write way back in the OS X 10.4 days. Back then, the OS did not have aggregate devices, so I coded it into my application. Even now, with OS support, I suspect the OS adds latency across all the devices in the a aggregate. With Apple of course, I can't look at their source code to see what it does. I need the master to have the lowest latency, so I kept my code in the application.</div><div><br></div><div>Ethan...</div><div><br></div><div>On Sun, 2019-11-17 at 11:03 +0100, Fons Adriaensen wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>On Sat, Nov 16, 2019 at 05:50:16PM -0700, Ethan Funk wrote:</pre><pre><br></pre><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>A very big structural difference between the APIs is how "rendering"</pre><pre>sample buffers is accomplished. </pre><pre>...</pre><pre>After years of tweaking the PID filter, I had it working very well,</pre><pre>with no cost (other than processor overhead of the re-sampling)</pre></blockquote><pre><br></pre><pre>If I understand what you write correctly, it seems to me that</pre><pre>zita-j2a and a2j are doing exactly the same thing. They contain</pre><pre>the separate callback, the resampler, buffering, and the control</pre><pre>loop.</pre><pre><br></pre><pre>E.g. for an output you'd have </pre><pre><br></pre><pre> buffer -> resampler -> hardware</pre><pre><br></pre><pre>Your separate callback would read the buffer, run the control</pre><pre>loop and the resampler, and write to the hardware.</pre><pre><br></pre><pre>The input to the buffer is where you connect to the world</pre><pre>controlled by the master card. If your master period size </pre><pre>is N, you would write to that buffer N samples during each</pre><pre>master card callback.</pre><pre><br></pre><pre>In other words, the input to the buffer is used in exactly</pre><pre>the same way as you would use zita-j2a's Jack ports. So I'd</pre><pre>be surprised if you really need any fundamental restructuring.</pre><pre><br></pre><pre>...</pre><pre><br></pre><pre>But what really surprises me is that you had to do the</pre><pre>resampling and buffering explicitly as part of your </pre><pre>application. Doesn't OSX provide this at the system</pre><pre>level (IIRC, by creating an 'aggregated' sound card) ?</pre><pre><br></pre><pre>Ciao,</pre><pre><br></pre></blockquote></body></html>