[squeak-dev] Sound mixing makes nasty noises
tim at rowledge.org
Mon Jan 4 01:31:58 UTC 2021
so yes, a Pi does indeed throttle when it gets hot - but hot is > 60C core temperature and believe me, none of my Pi ever get anywhere near that. Nor are they suffering low-voltage problems right now; I had a nasty issue with a failing PSU some time last year, or last century, whenever we think 2020 was. All fixed now with bigger margins on the supply.
It really does appear to be an issue with the basic design of the unix sound handling prims. Without digging too deep (because I'm knackered this weekend) it looks to me as if the unix sound prims are all single buffer stuff, whereas the Mac one appears double-buffered. For Windows I can't tell because none of the code makes any sense to me. For RISC OS there is a curious OS level buffering system that I vaguely understood for about 10 minutes 10 years ago.
Currently we by default create 120mSecs worth of buffer, fill it up and send it out to be played. Supposedly we can work out how many slots are free to refilled at any time but what does that even mean? It depends upon the details of the OS sound handling; if the OS takes a copy of the squeak buffer then in a sense said squeak buffer is now completely empty and ready to be filled completely. But what if the next attempt to pass a buffer finds that the OS cannot accept any more samples just yet? How complicated can we make this?
Even on a Mac you can trivially see the effect of some level of aliasing in the combination of the size of the buffer and the lengths of the 'notes' played by that snippet. Just try playing it with 'dur' set to 120 and then 150. Then edit the SoundPlayer class>>#initialize method to change the BufferMSecs value, then try again. It's really audible. But be careful - it appears to be possible to break the sound player completely by changing the BufferMSecs by much.
The problem seems to me that the interface is really set up for streaming not short chunk work. The Squeak side of it was designed 20 years ago on the basis of machines barely 1% as fast as the slowest machines we generally use these days (I'd guess a Raspberry Pi Zero would count for that) and has barely changed. We probably ought to do a lot better now.
> On 2021-01-02, at 11:02 PM, K K Subbu <kksubbu.ml at gmail.com> wrote:
> You can monitor actual latency on your sink/playback/output device with:
> ~$ pactl list sinks | grep -i 'sink\|latency'
That's seriously cool, thanks.
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful Latin Phrases:- Ne auderis delere orbem rigidum meum! = Don't you dare erase my hard disk!
More information about the Squeak-dev