Having a quick 30s think about this issue whilst waiting for some tea to brew....
If the audio is via SD, and you have a route input, then SD should "know" when you are leaving and arriving (taking off or landing). You could even mark a waypoint as a "busy" point to reduce less urgent audible messages, SD could then geofence those locations with a user settable radius / relative height and apply a configurable filter to help reduce the verbosity of the audio announcements. The radius could be set to accommodate the circuit, which would be part of your route setup. As not everywhere uses nice regular circuits, i.e. for noise abatement etc.
If it's the audio from PAW, that is harder, unless SD could send data back to PAW with the locations. Doing this exchange could be a simple as a grid reference and radius. The PAW could listen for a broadcast packet with the data in. Then all SD has to do is broadcast that packet, probably every few minutes in case the route changes. The "what to filter" could then be set in PAW, so future PAW updates (or any EC device with audio out) wouldn't need a tweak by SD. Broadcast is handy, as SD doesn't need to know the address of the EC device, and any EC device could listen for such data.
The definition of a packet containing a "quiet / do not disturb unless urgent" location would be fairly simple for SD to create, and broadcast. EC systems could listen for it, or not, probably quicker to sort out than an API for PAW, and then possibly needing another one for a different EC device elsewhere.
Edit, after a swig of tea. In fact SD could just transmit the next quiet location as the route progresses, or be told to do it with x radius of any aerodrome. That way any EC device only need to keep track of a geofenced location to filter. That might be a simple and efficient way of handling things.