That’s disappointing, and takes some of the shine off. At 48kHz, two buffers of 128 will create 5 mSec of latency, not counting the latency of the codec HW Itself. By itself that’s not an issue, but add in the latency of a stage wireless system or DAW or wireless in ear, plus the latency of distance from a speaker on stage, it adds up. That’s why I usually set the buffer size of Logic Pro to 64. Sometimes you can even get away with a buffer size of 32. And there is really no reason not to support a buffer size of even 32 on a bare metal embedded system, for god’s sake. Disappointing. Can I make feature requests, and are they honored?
Based on my experience, that’s an oversimplification. I don’t know which parts are used, but I have experience with the STM32 series of processors. On them, there are many types of memory, both external and internal. Program memory is usually internal flash, for an application like this that is usually sufficient. The cortex prefetch mechanism + cache usually insure that flash delays aren’t an issue. For data memory, there is usually internal SRAM, which is the fastest, and often slightly slower internal RAM. It’s often arranged in banks to tune speed. External RAM is the slowest. So for large delay buffers (echo, looping) and other huge consumers of RAM, external memory makes sense. But for other uses, like the delay buffers in IIR filters themselves, internal memory is the way to go. So this answer is confusing.
Again, disappointing, but the ecosystem I’ve put together for testing embedded code natively using python as a test harness, plus a porting pipeline to STM32 (Daisy), mean I can reduce the risk of issues before trying anything on the embedded system. So this one is merely an annoyance. The PolyEnd is valuable because of the physical packaging of codec and knobs and switches and the LED. Too bad the API and debug access aren’t a little more accommodating, though I do appreciate the need to protect IP.
I just hope that no one thinks the valuable IP is the SW “OS”. That may have been true in the past, but in the days of Claude Code it just isn’t anymore. The valuable IP is the HW packaging. That’s why I want one.
I do really appreciate the time you took to look into this, even though some of the answers are either disappointing or incomplete. At least I’m now well informed about the polyend system. The biggest disappointment is the lack of a buffer size adjustment. Also there is no easy way to introduce background processing in a different thread, which would be great for algorithms which have a slower frequency domain processing component. That’s not my focus presently, but it is something that could be accomplished without too much trouble.
I know because I just created an environment similar to the PolyEnd environment on the Daisy, from scratch, and not using any “HAL”, in just a few days using Claude Code. It helps that I have decades of embedded experience, but the value of the PolyEnd Endless to an independent developer is the physical packaging. So if anyone there wants to reach out or collaborate with someone like me who knows the territory, I’m all ears. Meantime I’ll consider whether the buffer size issue is a big problem for me. Here’s my stack up. 5mSec (polyend buffers) + 2mSec (codec hw) + 5mSec (stage wireless) + 7 mSec (distance from bass amp) = 19mSec. Based on my experience, that’s about where one begins to feel a bit disconnected from the sound. If I were using my Daisy system, I’d do a buffer size of 32 unless I started to run out of MIPs
