Hi Fons. On Wed, Jul 1, 2026 at 4:53 PM Fons Adriaensen <[email protected]> wrote: > > On Tue, Jun 30, 2026 at 09:00:29PM +0200, Matthias Geier wrote: > > > In the comments of the live stream there were a few questions and > > complaints that I would like to discuss here. > > I was the one who posted those comments. > > First of all, my remark that your solution was 'partially wrong' > was itself wrong. Sorry for that. I didn't have the paper available > then, the live stream was freezing all the time and audio quality > was poor so I probably misunderstood some of what you presented.
No problem. It's great to hear that you didn't find any factual errors. > But now that I have read the paper I stand by the other comments > I made. Which amounted to "Why on earth does anyone require a full > paper to present something as simple as > > min_delay = P - gcd (H,P) > > where H and P are the host and plugin block sizes. > > You really don't need pages of maths to find this out. > A bit of doodling on squared paper (similar to your fig. 1) > is all that is required. > > Assume for a moment that g = gcd (H,P) = 1. > > It's easy to see that in that case > > Delta (k) = (k * H) mod P, k = 0...P-1 > > will take on all values in 0...P-1 exactly once. > > So you'll have to accept a delay of P-1 samples. > > Now if g > 1, consider the buffer sizes > > H' = H / g > P' = P / g > > with one 'element' in each consisting of g samples, > and H' and P' being coprime. > > So the required delay will be P'-1 elements, or > (P'-1) * g samples, which is equal to P - g samples. > > QED. This is just Bézout's lemma in different words. > > The reason you won't find many papers about this is simply > that anyone with a bit of basic math knowledge can work > this out in a few minutes. It's easier than finding out the > classical way to solve a quadratic equation, and you won't > find many papers about that either - it's considered basic > knowledge, at least for anyone dabbling with computers and > DSP algorithms. Thanks for sharing this approach here! I think you are overestimating the mathematical prowess of many audio programmers (me included). I have no doubt that there are many people who have no problems finding the solution, either via the approach you showed or any other. But there are also many who would have problems, and for them (including me), it is very helpful to have this written down somewhere. If I would have found that anywhere, we probably wouldn't have written the paper. I also doubt that it's really "basic knowledge" (but that of course depends on how you define it), because if it would be, then Stéphane would have published the much simpler expression "P - g" in his paper instead of the more complicated loop-based solution he came up with. Even if it were "basic knowledge", and especially then, I would expect it to be explained in basic audio/DSP textbooks (like solving quadratic equations is explained in basic math textbooks). I have searched through several of them, and haven't found a single occurrence (except for the brief mention of the power-of-two case in Miller Puckette's book, which is referenced in our paper). If anyone reading this knows of more literature/web references, please post them here! BTW, I have created a PR to use the simpler solution for PortAudio: https://github.com/PortAudio/portaudio/pull/1161 Feel free to support or oppose that! I also found that in one of the cases when variable block sizes are allowed, the delay is one sample longer than it needs to be: https://github.com/PortAudio/portaudio/blob/f88b5841575b43bfa024a6861635b69d7eb98d6d/src/common/pa_process.c#L182-L186. I don't know if the behavior is relied upon in other parts of the codebase, so I didn't feel brave enough to make a PR for this as well. > Now if you like this sort of problems, Not really, to be honest. I didn't look into this because I was searching for a challenge, it just came up in a codebase I was working on, and I was looking for published solutions, and didn't find one (except for the implementation in the PortAudio codebase, at the time I didn't know about Stéphane's paper). cheers, Matthias > here are a few > that may be a bit more challenging. > > * The plugin can work only with one blocksize and sample > rate, so you need not only to buffer but also resample > at the input and output. > > - What is the minimal delay and how to achieve it. > - How to synchronise the two resamplers so that the > output sample rate exactly matches the input, > without roundoff errors resulting in accumulating > drift. > > * Same situation, but the combination of resamplers and > plugin must be able to accept a variable number of > samples in for each process() call, even if internally > the plugin has to use a fixed blocksize (e.g. for FFT > based processing). > > > Caio, > > -- > FA
