191–200 of 237 posts
Does not surprise me. I recently discovered that interrupting the close-all-apps-before-reboot workflow when applying a macOS upgrade (e.g., "don't terminate my terminal process yet, one sec, okay, I'm good to reboot now") requires a redo of the ENTIRE update process (including redownloading the 13GB update!)
Earlier quoted context omitted.
There are so many bugs and even more poor ergonomic choices that have been unfixed for years on Apple Devices. It's fascinating considering the whole cult regarding the company's so called attention to details.
It’s because despite those issues, depressingly macOS still delivers an experience that to most Mac users is preferable over that of Linux or especially Windows. Increasingly it’s not that macOS is incredible, but that the alternatives are that much worse. And I say this as someone who uses Windows and Linux daily alongside macOS. Windows isn’t going to get any better so long as Microsoft’s betting on pushing service…
Earlier quoted context omitted.
It’s because despite those issues, depressingly macOS still delivers an experience that to most Mac users is preferable over that of Linux or especially Windows. Increasingly it’s not that macOS is incredible, but that the alternatives are that much worse. And I say this as someone who uses Windows and Linux daily alongside macOS. Windows isn’t going to get any better so long as Microsoft’s betting on pushing service…
MacOS and Windows are, in my honest opinion, significantly less consistent experiences than Gnome. The list I have on MacOS UX annoyances, design inconsistencies and implementation bugs is in the hundreds.
Some of that consistency is also undone when it’s necessary to run Electron or Qt apps. Anki for example is a real pain if you’re using fractional scaling under Wayland, because GNOME’s refusal to implement server side decorations forces Anki to run with an ugly generic titlebar and no shadow. macOS is better here, with all programs getting the system default window treatment unless they request otherwise.
Earlier quoted context omitted.
I have just reported a bug where high memory pressure could cause memory pages from the real-time audio thread to get swapped out, causing audio glitches. I am not hopeful for a timely resolution now...
I have this using Firefox on a 2019 Macbook Pro with 16GB RAM. If the laptop has not been restarted for a while, Firefox tabs will eat up more and more memory over time until it makes the mac kind-of unresponsive (*) and will need to get hard power cycled. The only signs that this is about to happen are two: 1. Any audio-emitting webapp will start to get very choppy, whether is youtube on FF, Google meet on chrome, o…
Earlier quoted context omitted.
I have just reported a bug where high memory pressure could cause memory pages from the real-time audio thread to get swapped out, causing audio glitches. I am not hopeful for a timely resolution now...
this is the fault of a poorly designed application and not the OS
https://twistedwave.com/AudioGlitches.zip
It contains a program where the only thing I do in the real-time callback is to count the glitches, and I made sure to mlock() the memory used by the glitch counting code. When the memory pressure increases, it glitches.
Earlier quoted context omitted.
I have just reported a bug where high memory pressure could cause memory pages from the real-time audio thread to get swapped out, causing audio glitches. I am not hopeful for a timely resolution now...
This is not fixable. You’d need an RTOS. (You can’t mlock every single code page possibly executed by the thread for instance.)
I do my best to do it on the application side. It would be nice if Apple's CoreAudio did the same.
If you mean that it is difficult to identify the pages used, that is true, but I found a great way to do just that. I keep track of all the pages I mlock(), list all the remaining pages, and mprotect them to crash if I accidentally access memory that was not mlocked. That helped me identify a couple of pages I forgot, such as the one that contains the __stack_chk_guard
And regarding the code pages, for some reason I get a permission denied error if I try to mlock them. Not sure why.
There is no mlockall() on macOS, but if there was one, I could delegate the real-time audio handling code to a separate executable, and call mlockall(). I would be guaranteed all the pages used by the real-time thread would be mlocked.
And by the way if you are interested in the report I sent to Apple, you can find all the details with the sample code to reproduce the problem there:
Earlier quoted context omitted.
Err... Wasn't the entire point of the post that the bug is nearly 10 years old?
the person said they download 3rd party app 10 years ago I don't see anything there about contacting Apple
Edit: Apple was well aware of this issue (or a similar one), 12 years ago: https://web.archive.org/web/20221205223648/https://support.a...
Their response? "deal with it"
Earlier quoted context omitted.
this is the fault of a poorly designed application and not the OS
Here is the contents of the bug I have reported with all the details and sample code to reproduce the problem: https://twistedwave.com/AudioGlitches.zip It contains a program where the only thing I do in the real-time callback is to count the glitches, and I made sure to mlock() the memory used by the glitch counting code. When the memory pressure increases, it glitches.
The common form of this bug is way older than 10 years and isn't really specific to macOS. The problem is that audio devices do not have an explicit concept of "balance". It's set by adjusting the level of each channel. That volume adjusting process is not reliable. It often happens over an unreliable interface where some volume adjustments are just dropped. This hits a second problem: the audio device often has the…
Not sure if that's related to Apple's original problem, but in the scenario you are describing, the fix is trivial: detect when level commands are dropped and retry (up to N times / for up to X milliseconds). And don't forget to check existing volume between steps 1 and 2, so you can be made sure what the previous state was. I don't think the "fighting" will be a problem at all - you'd have to to press volume control…
I don’t know the macOS audio stack in detail, but I work on state synchronization problems in distributed systems and my intuition for problems like this is that the “why not just” solution almost never solves such a bug completely.