| Name | Modified | Size | Downloads / Week |
|---|---|---|---|
| Parent folder | |||
| Carrier_1.10.1_win_arm_portable.zip | 2026-08-18 | 3.2 MB | |
| latest.json | 2026-08-18 | 10.0 kB | |
| Carrier_1.10.1_win_arm_setup.exe | 2026-08-18 | 2.3 MB | |
| Carrier_1.10.1_win_x64_portable.zip | 2026-08-18 | 3.4 MB | |
| Carrier_1.10.1_win_x64_setup.exe | 2026-08-18 | 2.6 MB | |
| Carrier_1.10.1_lin_arm.AppImage | 2026-08-18 | 87.9 MB | |
| Carrier_1.10.1_lin_arm.rpm | 2026-08-18 | 4.3 MB | |
| Carrier_1.10.1_lin_arm.deb | 2026-08-18 | 4.3 MB | |
| Carrier_1.10.1_lin_x64.AppImage | 2026-08-18 | 93.0 MB | |
| Carrier_1.10.1_lin_x64.rpm | 2026-08-18 | 4.5 MB | |
| Carrier_1.10.1_lin_x64.deb | 2026-08-18 | 4.5 MB | |
| Carrier_1.10.1_mac_intel.dmg | 2026-08-18 | 3.8 MB | |
| Carrier_1.10.1_mac_arm.dmg | 2026-08-18 | 3.5 MB | |
| README.md | 2026-08-18 | 1.2 kB | |
| v1.10.1 source code.tar.gz | 2026-08-18 | 3.8 MB | |
| v1.10.1 source code.zip | 2026-08-18 | 4.0 MB | |
| Totals: 16 Items | 225.0 MB | 0 | |
Carrier 1.10.1 reduces how much an idle Messenger tab interferes with Bluetooth audio on macOS.
Bug Fixes
- Fewer Bluetooth audio dropouts while Carrier is open (partial fix). Messenger keeps a Web Audio context running even when nothing is playing, and macOS treats that as an active audio session: it competes with whatever you are actually listening to for the Bluetooth route (each swap restarts the stream, which you hear as a dropout), and its always-on silent render can stall the shared output device under load, muting AirPods system-wide. Carrier now suspends that context whenever Messenger has nothing to play and resumes it the moment a sound, call, or media stream needs it. Notification sounds are unaffected: they are played by macOS, not by the page.
This is a mitigation, not a full fix. On macOS 27 WebKit restarts the audio render about a second after the page suspends it, below anything the page can see or control, so the context still spends part of its time active. If you notice a dropout, quitting Carrier for the duration of a call or listening session remains the reliable workaround. Progress and the underlying WebKit finding are tracked in [#234].