Environment
- Rootshell: current TestFlight build installed after
1.0.9 (124); exact current build number was not recorded
- iPad 10th generation on iPadOS
26.5.2
- Mac mini M2 Pro, 16 GB, macOS
26.5.2 (25F84)
- Screen Sharing: High Performance, Match Client, One Virtual Display
- Connection: direct macOS Screen Sharing through Tailscale
- Rootshell virtual display:
2368 × 1536, UI 1184 × 768 @ 60 Hz
- The saved profile is configured with
Play Remote Audio off. I did not capture the toggle on screen immediately before this run, so I cannot claim visual proof of its state at connection time.
Problem
Connecting through Rootshell High Performance immediately makes the Mac's coreaudiod consume roughly 150–180% CPU while avconferenced consumes roughly 11–18%. The one-minute load average then climbs continuously until Rootshell disconnects. This can make the entire Mac unresponsive.
The Screen Sharing session itself works: typing and GUI control from the iPad reach the Mac. The problem is the host load created while that working session is active.
Reproduction
- Start from the Mac with Rootshell disconnected.
- Confirm normal host state (
coreaudiod and avconferenced near 0% CPU).
- Connect from the iPad using High Performance, Match Client, One Virtual Display.
- Use the session normally for about one minute.
- Sample Mac load and the relevant processes every five seconds.
- Disconnect Rootshell and continue sampling.
Observed on 2026-07-30
Baseline before connection:
- load average:
2.80
- memory free:
45%
coreaudiod: 0.0%avconferenced: 0.0%
After connection:
| Approx. time after connection |
1-minute load |
coreaudiod |
avconferenced |
| 15 s |
4.26 |
163.8% |
13.6% |
| 20 s |
12.16 |
148.0% |
14.4% |
| 26 s |
21.60 |
181.2% |
17.2% |
| 41 s |
32.17 |
151.4% |
16.9% |
| 51 s |
37.52 |
146.7% |
14.5% |
| 72 s |
63.62 |
147.9% |
13.0% |
During the active session:
screensharingd held the TCP 5900 connection.avconferenced held the High Performance UDP 5900/5901 media path to the iPad.- Memory remained usable at roughly
32–45% free, so this was not initiated by memory exhaustion.
- No kernel panic or watchdog crash occurred because the session was disconnected before the load climbed further.
On disconnect, coreaudiod immediately dropped from roughly 150% to low single digits. It briefly oscillated during cleanup, then returned to 0%; avconferenced returned to 0%, and the load average began decaying.
This is not a one-off. Earlier tests on builds 122 and 124 showed coreaudiod around 211–239%, avconferenced around 15–18%, and host load as high as 145–149. The 2026-07-30 run reproduces the same failure on a newer TestFlight build with a cleaner before/during/after time series.
Expected
Rootshell High Performance Screen Sharing should not create sustained coreaudiod CPU load or an unbounded host-load climb. When Play Remote Audio is off, the remote-audio path should not initialize or render continuously.
Could you check whether High Performance mode is constructing an AVConference/CoreAudio audio pipeline even when remote audio is disabled? I can run a diagnostic build or collect a targeted macOS sample/log if useful.
Environment
1.0.9 (124); exact current build number was not recorded26.5.226.5.2 (25F84)2368 × 1536, UI1184 × 768 @ 60 HzPlay Remote Audiooff. I did not capture the toggle on screen immediately before this run, so I cannot claim visual proof of its state at connection time.Problem
Connecting through Rootshell High Performance immediately makes the Mac's
coreaudiodconsume roughly 150–180% CPU whileavconferencedconsumes roughly 11–18%. The one-minute load average then climbs continuously until Rootshell disconnects. This can make the entire Mac unresponsive.The Screen Sharing session itself works: typing and GUI control from the iPad reach the Mac. The problem is the host load created while that working session is active.
Reproduction
coreaudiodandavconferencednear 0% CPU).Observed on 2026-07-30
Baseline before connection:
2.8045%coreaudiod:0.0%avconferenced:0.0%After connection:
coreaudiodavconferencedDuring the active session:
screensharingdheld the TCP5900connection.avconferencedheld the High Performance UDP5900/5901media path to the iPad.32–45%free, so this was not initiated by memory exhaustion.On disconnect,
coreaudiodimmediately dropped from roughly 150% to low single digits. It briefly oscillated during cleanup, then returned to 0%;avconferencedreturned to 0%, and the load average began decaying.This is not a one-off. Earlier tests on builds
122and124showedcoreaudiodaround211–239%,avconferencedaround15–18%, and host load as high as145–149. The 2026-07-30 run reproduces the same failure on a newer TestFlight build with a cleaner before/during/after time series.Expected
Rootshell High Performance Screen Sharing should not create sustained
coreaudiodCPU load or an unbounded host-load climb. WhenPlay Remote Audiois off, the remote-audio path should not initialize or render continuously.Could you check whether High Performance mode is constructing an AVConference/CoreAudio audio pipeline even when remote audio is disabled? I can run a diagnostic build or collect a targeted macOS sample/log if useful.