I am testing a Vision Pro for work, and I did not see the beta updates when signed into this Apple ID. I have a paid developer account. What I had to do as a workaround was sign into a different Apple ID: specifically, a managed Apple ID owned by my organization. I happen to be a top level administrator in our Apple Business Manager instance, so I used that one. When I sign in using that Apple ID on the Vision Pro, suddenly I can enable the beta updates for the visionOS and enroll in the "Appleseed" beta program. I updated the headset to vOS 1.2 beta 2, then signed out of that Managed Apple ID. I signed back in using my personal Apple ID. Now, in Software Update, I am still able to receive updates. The "Appleseed" beta has a warning triangle because it isn't available to my standard developer account, so I switched to the Developer beta (not the Public beta). vOS 1.2 beta 3 is available, but it warns me that the Apple ID cannot participate in this beta program (or something to that effect). Paid developers should not have to do anything special on the headset or in their accounts to see the betas within vOS' software update pane. In my case, my iPhones and Macs signed into this Apple ID can all see the option to enable beta updates.

Bumping this thread to the top of the list. I am testing a Vision Pro for work, and I did not see the beta updates when signed into this Apple ID. I have a paid developer account. What I had to do as a workaround was sign into a different Apple ID: specifically, a managed Apple ID owned by my organization. I happen to be a top level administrator in our Apple Business Manager instance, so I used that one. When I sign in using that Apple ID on the Vision Pro, suddenly I can enable the beta updates for the visionOS and enroll in the "Appleseed" beta program. I updated the headset to vOS 1.2 beta 2, then signed out of that Managed Apple ID. I signed back in using my personal Apple ID. Now, in Software Update, I am still able to receive updates. The "Appleseed" beta has a warning triangle because it isn't available to my standard developer account, so I switched to the Developer beta (not the Public beta). vOS 1.2 beta 3 is available, but it warns me that the Apple ID cannot participate in this beta program (or something to that effect). Paid developers should not have to do anything special on the headset or in their accounts to see the betas within vOS' software update pane. In my case, my iPhones and Macs signed into this Apple ID can all see the option to enable beta updates.

@asmbaty : this Apple we're talking about here. You should just expect that frameworks will be exposed to future changes without warning.

A fellow Mac sysadmin working at a company with a large population of Mac users opened a ticket with Zoom, Inc., about this issue. Zoom responded today with this: "We've asked our product team for an update, and they said that fixing this issue involves several modules in the Zoom client. We aim to address [the changes to ScreenCaptureKit] in Zoom client version 6.0.0. Currently, we are on version 5.17.7, so it seems to be about 4 release cycles away. We usually publish a new client version every 1 to 2 weeks." Take that in for a second: The de facto king of screen-sharing software says that they need 4-8 eight weeks (aka 2-4 Agile sprints) to incorporate this new framework. And Zoom is one of the more NIMBLE software developers in this space. I can't imagine how long it's going to take Cisco, Microsoft, BlueJeans, Teradici, Teamviewer, and countless others to refactor their app to ScreenCaptureKit. This is why Apple needs to publish deadlines and give their developers heads-up before displaying confusing and alarming messages on customers' screens, as they did in the 14.4 betas.

I googled the error and found this thread. Thank you for posting it. There's a reddit post that links here, too. I am experiencing this issue on a 2018 MacBook Pro (T2, Intel Core i7) running macOS 12.6 Monterey. The Mac needs to be running continuously for a LONG time before the issue starts to occur. My Mac's uptime is about 75 days right now. All applications using audio are affected when the default device is the external USB adapter. The issue goes away immediately if I switch to something else, like the internal speakers. Examples of aberrant behavior: Teams hangs for 30 seconds while starting a call and becomes unresponsive Videos in Safari will freeze, then "catch up", then freeze, and repeat every 3-5 seconds. Apple Music plays for about 3 seconds then goes silent. I am using a CalDigit TS3+ docking station and the USB device in question is a simple headset/mic adapter branded UGREEN. I bought it from Amazon. According to Audio MIDI Setup, my present audio configuration for the USB device is 16bit, 2 channel, 48kHz. So far I have tried: Killing the coreaudiod service Quitting / relaunching the affected apps Unplugging / reconnecting the USB device Plugging the USB device directly into the Mac (bypassing the hub) Changing the sample rate from 48kHz to 44kHz. None of these actions improved the behavior. I made an interesting discovery: every time I killed coreaudiod, my primary external monitor went blank for about two seconds. The primary monitor is a Dell 4K connected via the CalDigit TS3+ hub's DisplayPort output. My secondary external monitor, however, did not go blank when killing coreaudiod. That monitor is also DisplayPort, but connected via a Thunderbolt > DisplayPort adapter on the CalDigit TS3+. I can repeat this behavior with coreaudiod ad nauseam and have been gathering a sysdiagnose as I write this. The USB audio device in question is an inexpensive UGREEN branded headset/mic adapter that I bought from Amazon. According to System Profiler, the vendor ID is Realtek Semiconductor (0x0bda) and the Product ID is 0x4809. What are your USB audio device's vendor and product IDs? Have we found any in common? There's a slightly different yet similar error when recording or monitoring audio, even if you're just watching the Input tab in System Preferences: 2023-01-09 15:24:56.298594-0800 0x3edf369  Default     0x0                  34738  0    coreaudiod: (CoreAudio)  index: 49, start: 0x1768beb4151d25, duration: 0x5d6, fault address: 0x7fd07175c000, fault pc: 0x7ff80f17f28f, faulting TID: 0x3ee1bb9, fault type: 0x9, PID: 0x296ea4 2023-01-09 15:24:56.298625-0800 0x3edf369  Default     0x0                  34738  0    coreaudiod: (CoreAudio)  index: 50, start: 0x1768beb55a781e, duration: 0x178b, fault address: 0x7fd07173b000, fault pc: 0x7ff80f17f28f, faulting TID: 0x3ee1bb9, fault type: 0x9, PID: 0x296ea4 2023-01-09 15:24:56.298648-0800 0x3edf369  Default     0x0                  34738  0    coreaudiod: (CoreAudio)  index: 51, start: 0x1768beb55a9515, duration: 0x6d6, fault address: 0x7fd07174c000, fault pc: 0x7ff80f17f28f, faulting TID: 0x3ee1bb9, fault type: 0x9, PID: 0x296ea4 [...repeated several times...] 2023-01-09 15:24:56.300733-0800 0x3edf369  Default     0x0                  34738  0    coreaudiod: (CoreAudio)  Audio IO Overload thread: 3ee24c4 inputs: '<private>' outputs: '<private>' cause: 'Unknown' prewarming: no recovering: no 2023-01-09 15:24:56.301066-0800 0x3edf369  Default     0x0                  34738  0    coreaudiod: (libAudioStatistics.dylib) [com.apple.coreaudio:carc]      CAReportingClient.mm:508   message {     "HAL_client_IO_duration" = 100285;     HostApplicationDisplayID = "com.apple.systempreferences";     cause = PageFaultsOffIOThread;     deadline = 48268;     "input_device_source_list" = Unknown;     "input_device_transport_list" = USB;     "input_device_uid_list" = "AppleUSBAudioEngine:Generic:USB Audio:00:1";     "io_buffer_size" = 512;     "io_cycle" = 413;     "io_cycle_budget" = 5222463225846134107;     "io_page_faults" = 0;     "is_prewarming" = 0;     "is_recovering" = 0;     "issue_type" = overload;     lateness = 38718;     "other_active_clients" = "[ { HostApplicationDisplayID_other_client: com.apple.systempreferences, sample_rate_other_client: 0.000008, io_buffer_size_other_client: 512 } ]";     "other_page_faults" = 52;     "output_device_source_list" = "";     "output_device_transport_list" = "";     "output_device_uid_list" = "";     "safety_violation" = 0;     "sample_rate" = 48000;     "scheduler_latency" = 54208;     "smallest_buffer_frame_size": <decode: missing data> Since this is my work laptop, I filed a case with AppleCare for Enterprise and included a sysdiagnose after the problem was occurring, and also another taken while reproducing the issue, so that the diagnostics will capture memory footprints, spindumps, etc., of the affected process. I'm hoping we all get to the bottom of this soon. What about Ventura? Has anyone with this issue seen an improvement there?

In addition to my request about whether you filed feedback... you should know that the '--restart' option does not work on Macs with Apple Silicon. Apple doesn't let 'root' do this for some godforsaken reason, even though forcing a machine to install updates signed by Apple poses absolutely no security risk to the user. And before someone says 'on Apple Silicon, it requires a volume owner to enter their password to approve the updates' — I'm well aware of the mechanics and how it is connected to iOS, where the user enters their passcode to allow updates to install when the device is idle. The question is... WHY was this security mechanism implemented on the Mac, and why can't root trigger the update cycle anymore. It added a lot of management headache for little tangible benefit to administrators.

Obligatory : "Did you file feedback with Apple?" Seriously, though, can you share the FB # and have you received any response from Apple about this? One of the default settings in Jamf is to simply run softwareupdate to check for available updates, not even to enforce them. This check triggers the User Notification. And the problems seem to have started with Big Sur.

Thank you, nameless  Systems Engineer! The community has discussed asking for a 'recording light' in macOS 10.16 / macOS 11, similar to what iOS 14 is shown to have. This icon in the menu bar would show users when their screen is being recorded, and what app(s) are doing that (in a menu). See FB7801822 for an example.

I totally understand if Apple is doing this because it believes children at home should absolutely not be able to allow screen recording for the whole system. This is why parents are admin users, and children should be standard users with parental controls and so forth. If the recent FleetSmith acquisition enables Apple to create an "MDM lite" for family sharing and enhanced parental controls, that's great. What this thread is about, on the other hand, is ADULTS trying to ADULT. From apple.com/business - www.apple.com/business: "Apple products help employees work more simply and productively, solve problems creatively, and collaborate with a shared purpose. And they’re all designed to work together beautifully. When people have the power to work the way they want, with the tools they love, they can do their best work." This change in Big Sur is making it much harder to continue doing that, and it *will* impact future sales of Mac hardware ... unless Apple makes some concessions for responsible admins trying to make life easier for their end users. SUGGESTION: iOS 14 has this new "recording" light feature for the status bar. Why can't MacOS have a similar indicator in the menulet that resembles a tiny computer screen with a blinking red light while screen recording is active? Here's what I would do: Add a key for Screen Recording under PPPC in the MDM spec. Add a key value that allows the above setting ONLY when supervised. Add a recording light to macOS Big Sur so ALL users know when the screen is being recorded, regardless of how screen recording was approved. Justification: Large institutions and schools often have security policies that seek to minimize attack surface and simplify troubleshooting by defaulting users to non-admin (standard) rights unless they have special permission or business justification to be admins on their machines. The same also make heavy use of collaboration and virtual meeting tools like WebEx, Zoom, MS Teams, and so forth. Virtual meetings and remote presentations are on the side due to COVID-19. Screen sharing is an essential function remote support tools like LogMeIn and Bomgar, where the technician must be able to see the user's screen to guide them through troubleshooting. PS: AppleCare uses a rebranded version of Bomgar, so they're about to find out what a pain this is going to be for some customers who call for help.