SoundFerry journal
Missing AirPlay or Cast speakers: Mac checks
By SoundFerry · Published
When an AirPlay or Google Cast speaker is missing on a Mac, first name the list it is missing from and the last stage that worked. A receiver absent from SoundFerry, one visible but unable to connect, and one connected without sound require different checks. Start with one receiver and preserve that distinction before changing permissions or the network.
This is a proposed diagnostic workflow, not a report of tests on your equipment. It adds a decision path and a record you can share with support. It does not promise discovery of every speaker or ask you to weaken a network’s security to make a connection work.
Name the list and the failed stage
Write the sender app, receiver model and intended protocol at the top of your notes. “Missing on my Mac” is too broad: Apple’s AirPlay picker, a Cast-enabled app and SoundFerry are different observation points. A comparison is useful only if the receiver supports the method being checked.
| Last observation | Follow this branch | Do not conclude yet |
|---|---|---|
| No receiver name in the intended sender | Verify capability, availability, app access and network membership. | The audio driver is broken. |
| Name appears but selection or connection fails | Record the message and check authorization or receiver availability. | Discovery itself failed. |
| Selection succeeds but the receiver stays silent | Confirm local source audio, output selection and volume. | The receiver is missing. |
| One receiver plays but another does not | Test the second alone through the same route. | Every output needs a timing adjustment. |
| Both play but sound misaligned | Move to a listening and timing investigation. | More discovery changes will fix the echo. |
If a list has no matching protocol, stop that comparison. A Cast-only receiver does not need to appear as an AirPlay destination. Check the exact model against its manufacturer’s specifications and our speaker compatibility guide before treating an absent name as a fault.
Establish one receiver’s availability
Choose a receiver you can identify physically. Record its displayed name and model so a renamed device is not mistaken for a missing one. Confirm that it has power and is awake, and use its own supported controls or manufacturer’s app to check its network connection and required playback capability.
Apple’s AirPlay troubleshooting guidance begins with compatible powered devices, current software, a shared network and retesting after each step. It also discusses AirPlay access restrictions for devices configured in the Home app. Apply receiver-specific guidance only to the device you actually have; do not assume every network speaker exposes Apple’s Home settings.
Do not perform a factory reset just to establish this baseline. It can remove the configuration you are trying to describe. First record whether this receiver has ever worked through this sender, whether its name changed, and whether the symptom followed sleep, an update or a network move.
If several receivers are absent, still choose one for the next check. A single well-described case is easier to compare than a list of changing rooms. Leave the larger Mac multi-room arrangement aside until the individual path is understood.
Check the sender’s applicable Local Network permission
Apple documents app-level local-network access in System Settings > Privacy & Security > Local Network. The controls apply to apps listed there. Check the app performing the discovery operation, rather than assuming a permission given to another app also covers it.
Google’s casting permission instructions specify macOS 15 or later for that Mac workflow. This version scope matters: SoundFerry also supports macOS 14, so do not tell every supported Mac user to find an identical permission screen. Record the macOS version and consult the applicable system guidance if the control is unavailable.
For SoundFerry discovery or a connection error, inspect SoundFerry’s relevant entry if present. For a separate Chrome casting comparison, inspect Chrome’s applicable access instead. Granting Chrome access is not evidence that SoundFerry has access, or vice versa. Browser site permissions are another layer; do not import browser instructions into a native-app diagnosis without an applicable browser symptom.
If the expected entry or prompt is absent, record that fact and the operation you attempted. Do not repeatedly revoke permissions, run terminal reset commands or create an unverified sequence intended to force a prompt. Continue with the other observations and include the missing control in a support record.
Ask whether the network allows the devices to communicate
Internet access on both devices does not settle the local connection question. Note the network each device is configured to use, including whether one is a guest connection, an extender connection or a wired connection. Similar network names alone are not a complete description of how devices can communicate.
Google’s Cast FAQ identifies AP or client isolation, including on extenders, as a barrier to Cast communication and describes restrictions on isolated guest or public networks. That explains a question to ask; it is not a reason to disable router protections indiscriminately.
On a network you manage, read its documentation to determine whether the intended Mac and receiver can discover and communicate with each other. On a workplace, hotel or other shared network, ask its administrator for a supported arrangement. Do not change settings you do not own or treat successful internet browsing as proof of receiver reachability.
Keep the question specific: “Can this Mac communicate locally with this receiver on these connections?” Avoid collecting unrelated router toggles from different products. If the administrator confirms that isolation is intentional, stop troubleshooting it as a speaker defect and discuss an approved network arrangement instead.
Separate discovery from pairing and selection
Return to the intended sender and record whether the receiver is now listed. In SoundFerry, use the Speakers view and its reload control for a deliberate recheck; avoid repeatedly pressing it while another operation is underway. Record the result of the recheck rather than assuming a refreshed list guarantees playback.
If the name appears but selecting it fails, copy the actual message. SoundFerry’s connection-error guidance includes checking local-network permission and shared network membership. A listed receiver can therefore still need an access or communication check. Discovery and subsequent connection should remain separate rows in your notes.
Some receivers request a pairing code or configured password. Follow the prompt on that receiver and the SoundFerry setup and pairing guide. Do not guess a universal PIN or assume a previously authorized device can never ask again. Record whether authorization was requested, accepted or failed, without including the secret itself.
For a comparison with another sender, stop SoundFerry streaming before testing that sender, as described in the product’s troubleshooting instructions. Keep the receiver and network unchanged. A successful comparison narrows the question but does not prove that every sender has identical protocol support or authorization behavior.
After connection, prove the local audio path
Once a receiver is selected, verify that the source is producing local Mac audio. SoundFerry runs on a Mac and routes that local audio to selected compatible AirPlay and Google Cast outputs. It is not an iPhone routing app, and a remote Spotify Connect session on a speaker does not pass through the Mac output.
Check the selected Mac output and any actual source-app output control, then check mute and comfortable volume levels. Follow the Spotify-on-multiple-speakers guide when Spotify is your source. Do not infer local audio from a moving playback indicator alone.
Test the receiver alone before adding a second. Allow buffered playback to begin, and note the difference between never hearing audio and hearing audio that subsequently stops. Neither observation is the same as an absent receiver. Use the general AirPlay troubleshooting guide to continue from the matching symptom.
If both receivers play but their sound overlaps poorly, end the discovery investigation. Our paired echo and delay test addresses a different problem. Successful discovery and single-receiver playback do not guarantee grouping compatibility, alignment or long-duration stability.
Keep a staged record and stop at the right boundary
Use one row per attempt, including the sender and its version, receiver model, intended protocol, macOS version, network connections and the last successful stage. Add the permission observation, whether the name appeared, the result of selection, any authorization prompt and the audible result. Write “not checked” where appropriate rather than implying a completed test.
A useful record might say: “Receiver A is absent from SoundFerry, present in another compatible sender after SoundFerry streaming was stopped, and has not yet been tested for selection in SoundFerry.” That wording preserves what is known and what is still unknown. It does not say the receiver is fully working just because a different list contains its name. Another row can record the same receiver becoming visible but requesting authorization; that is progress to a new stage, even if music has not started. Keep those rows instead of replacing the first observation with a general statement that nothing works.
Change one applicable item, then repeat the same failed stage. If a receiver starts working, record what changed before expanding the group. If the result differs without a setting change, record both outcomes; do not convert a single successful retry into a claim that the cause is fixed.
Stop making discovery changes when the receiver connects and plays. Stop changing local controls when the limitation belongs to a managed network or an unsupported protocol. If several attempts remain inconclusive, use the SoundFerry troubleshooting guide with your record and exact error. That gives support a reproducible starting point while preserving your working settings and the network’s intended access controls.
Frequently asked questions
Does a speaker appearing in a list prove it can play?
No. Discovery, selection, authorization and audible playback are separate observations. Note which list shows the receiver, whether selection succeeds, any pairing message and whether local audio reaches it. A visible name is not a guarantee of a usable audio path.
Where is Local Network permission on a recent Mac?
Apple documents System Settings > Privacy & Security > Local Network, with controls for listed apps. Google's Cast guidance specifies macOS 15 or later for this Mac permission workflow. Check the relevant listed sender app, not an unrelated browser or phone.
Should I disable network security to discover speakers?
Do not broadly disable protections as a diagnostic shortcut. Record whether the Mac and receiver are on an intended network that permits local device communication. Ask the network owner about isolation and supported access when necessary.
Does a Cast receiver need to appear in Apple's AirPlay list?
No. Compare lists only when the receiver and sender support the same playback method. A Cast-only device missing from an AirPlay picker does not establish a discovery failure. Verify the exact model and intended protocol first.
What if a receiver is listed but asks for a code?
That is a different stage from being absent. Follow the receiver's actual pairing or password prompt and the sender's setup instructions. Do not invent a default code or remove access restrictions merely to avoid authorization.
Should I adjust delay when a speaker is missing?
No. Establish discovery, connection and audible individual playback first. Delay controls concern timing between playing outputs; they cannot reveal an absent receiver or generate missing local Mac audio.
Sources and editorial context
Official documentation checked on 2026-10-19. This comparison is published by SoundFerry, which develops a Mac audio routing app. It describes documented behavior and setup decisions; it is not a hardware benchmark.