I am interested in technologies that could make sensory support more personal and responsive without removing the traveller from the environment completely. This paper stood out because Sona does not simply block all sound like conventional noise-cancelling headphones. It tries to reduce selected unwanted sounds while keeping other parts of the soundscape available.

That feels particularly relevant to an airport, where reducing noise may help but completely suppressing the environment could also remove important information such as announcements, staff instructions, alarms or other orientation cues.

This paper is also useful because it gives me a comparison point for biosensing. Sona is responsive and personalised without using physiological data. It responds to the acoustic environment and to the user's choices. That makes it useful for asking whether biosensing genuinely adds something, rather than assuming that every personalised system needs it.

What Sona is

Sona is a mobile soundscape-mediation system for people with sound sensitivity. It processes sound from the environment and lets the user selectively attenuate specific sounds rather than reducing everything equally.

The system can reduce multiple overlapping sounds at once, and the user can adjust the attenuation strength from 0% to 100%. This means a sound does not always need to disappear completely; it can be softened while still remaining audible.

Sona also uses sound recognition to suggest sounds that might be useful to attenuate. Users can accept or ignore these suggestions, and they can create their own custom sound classes by recording sounds from their environment.

What I find most important is that the technology is trying to create a filtered version of the real soundscape, rather than replacing the soundscape with silence.

Why selective attenuation matters

The paper begins from a limitation of existing tools such as earplugs and noise-cancelling headphones. These can reduce discomfort, but they also suppress useful auditory information.

Sona therefore separates two needs that are often treated as the same thing: relief from bothersome sound and continued awareness of the environment.

The authors' formative survey with 68 people who experience sound sensitivity found substantial variation in which sounds were bothersome and how participants wanted them changed. Reduction and removal were the most common preferences, but the preferred level of intervention differed by sound type and perceived annoyance.

This is consistent with my wider project position that sensory support cannot be based on one fixed setting. The relevant question is not simply whether an airport is “quiet” or “loud”, but which sounds are difficult for a particular person, how strongly they want them changed, and which sounds they still need access to.

Autism and sound sensitivity

The paper uses the broad term people with sound sensitivity, including experiences such as misophonia and hyperacusis. The participants in the Sona study were recruited around sound-sensitivity experiences rather than autism specifically.

However, the paper directly connects sound sensitivity with autism literature. It cites a meta-analysis estimating hyperacusis in 41.4% of autistic people at the time of measurement and 60.6% at some point in their lives.

I need to keep this distinction clear. This does not mean Sona was tested as an autism intervention. It does show why personalised auditory accessibility is relevant to autistic experience and why a system that preserves useful sound while reducing selected triggers is worth investigating in my airport context.

How the system works

Sona runs on a smartphone and processes incoming environmental audio in real time. The system uses a neural attenuation model that can target several selected sound classes in one pass.

Users can choose from built-in sound classes and adjust the strength of attenuation. The system also recognises sounds in the environment and can surface a short suggestion that the user can tap if they want that sound reduced.

For sounds that are not already represented, the user can record short examples and give them a label such as “blender” or “mechanical whirring”. Sona uses these examples to create a reusable custom sound class without retraining the whole model.

In the study setup, Sona ran on an iPhone with an external microphone and wired Sony headphones. The important point for me is that the system modifies the audio delivered through the headphones. It does not remove sound from the physical environment.

What the researchers tested

The researchers first conducted an online survey with 68 adults who reported sound sensitivity to understand which sounds were difficult and how people preferred to manage them.

They then carried out an in-situ evaluation with ten adults aged 19–51 who experienced sound sensitivity. Each participant took part in a single session lasting around two hours.

Participants used Sona in two campus settings: a relatively quiet study lounge and a busy food court. They completed simple activities while natural and staged sounds occurred around them, then tested the system's personalization workflow and took part in a semi-structured interview.

This gives the paper more ecological relevance than a purely laboratory-based audio test, but it is still a small, short-term evaluation rather than evidence of sustained everyday use.

What stood out to me

The strongest idea for me is that Sona tries to reduce sensory demand without removing orientation and awareness.

Participants generally reported that the system made the soundscape more comfortable, and most noticed that it reduced bothersome sounds. They also valued still being able to hear speech and other environmental cues.

This becomes especially relevant when participants discussed real-world situations. Some imagined using Sona in public places where they wanted to reduce distracting sounds while remaining aware of conversations and what was happening around them.

That directly connects to my airport thinking. An airport support system cannot simply optimise for maximum noise reduction. It also has to consider what the traveller needs to hear in order to remain oriented and independent.

The limitation in my sticky note

My main sticky note was that the user may have to operate the system while they are already experiencing the triggering sound.

The paper identifies this problem directly. Manually capturing or selecting a trigger can require the person to interact with the interface at the same moment that the sound is interfering with attention, information processing or self-regulation.

This feels extremely important for my project. A system can be technically easy to use and still place interaction demands at the worst possible moment.

Participants described this in the evaluation. Some said selecting filters or responding to multiple suggestions became distracting and extended the disruption caused by the original sound. In a rapidly changing environment, managing the support system can become another task layered onto the situation.

For an airport, that could mean trying to configure sound filters while also finding a gate, watching luggage, listening for announcements or moving through security.

Automation versus control

Participants had different views on how much the system should automate.

Some wanted familiar unwanted sounds to be filtered automatically so that they did not have to repeat the same interaction. Others preferred deliberate configuration because control over the system was itself important.

I find this tension very relevant. Automation could reduce interaction burden, but it could also suppress a sound the traveller actually needs in that context.

The paper includes a particularly useful example from transit: filtering the sound of bus doors could reduce an unwanted sound but also remove a cue someone uses to understand how many stops have passed. Another participant suggested a “never cancel” list for important sounds.

For my airport project, that makes me think about an equivalent protected layer: certain sounds may need to remain available regardless of a regulation setting, such as staff speech, boarding calls or emergency alerts.

Personalisation is not automatically simple

Sona's personalization is one of its strongest features, but the study also showed that custom attenuation worked unevenly.

Most participants experienced only partial reduction of their custom target sounds. Some found that adding more examples improved the result, while others were unsure whether the system had learned what they intended.

Participants wanted clearer feedback about what the system had understood and whether their recordings were actually improving the custom filter.

This is useful for my broader project because personalisation can sound like an obvious solution to heterogeneous sensory needs, but it creates its own design work. The user needs to understand what has been personalised, how well it works and what the system will do next.

Does this need biosensing?

Sona does not use biodata. Its inputs are environmental sound, sound-recognition models, stored sensitivity profiles and direct user choices.

That makes it an important challenge to my current biosensing direction. A system can already become responsive and individualised by understanding the environment and remembering preferences.

If I explored a biosensing layer alongside something like Sona, I would need to justify what it adds. One possibility would be for a sustained physiological change to trigger a prompt offering a previously configured sound profile, rather than automatically changing the soundscape.

I would be much more cautious about allowing physiological data to automatically increase attenuation strength. A change in heart rate or skin conductance cannot tell the system which sound is causing difficulty, and automatically suppressing audio could remove information the traveller needs.

So the design question becomes: is biosensing necessary for the response, or could environmental sensing and manual preference already provide the more reliable form of control?

Airport relevance

This paper feels unusually relevant to an airport because airports are both sensory environments and information environments.

The traveller may want relief from background machinery, crowd noise, repetitive sounds or other personally difficult inputs, while still needing to hear gate changes, staff instructions, boarding information and warning signals.

Selective attenuation therefore offers a more nuanced design territory than full noise cancellation. It potentially supports regulation while preserving orientation.

At the same time, the participants were cautious about unpredictable, crowded environments. Some felt the setup and interaction demands would make Sona less suitable when the soundscape changed quickly. That is exactly the kind of condition an airport can create.

This means Sona does not automatically solve the airport problem. It helps me identify a more specific challenge: how could auditory support preserve essential cues while reducing individual sensory demand without requiring constant management?

Privacy and public use

The paper also raises privacy concerns that would become more significant in an airport.

Sona's live attenuation operates on-device, but parts of the personalization process in this prototype use server-hosted models. Participants wanted control over when audio was captured, uploaded and retained, and some were uncomfortable with the possibility of continuous listening or recording other people's voices.

For my project, this reinforces that a responsive wearable cannot treat sensing as invisible infrastructure. The user needs to know when sensing is active, what data leaves the device and how to stop it.

Limitations

This is a 2026 arXiv preprint, so I should treat it as emerging work rather than established evidence of effectiveness.

The user study involved only ten participants in one approximately two-hour session. The two environments were real campus spaces, but the researchers also introduced staged sounds, so the study does not fully reproduce uncontrolled everyday use.

The prototype also used mono 16 kHz audio and did not preserve spatial hearing cues. This matters for an airport because where a sound is coming from can be part of orientation and safety.

The study did not formally compare Sona with active noise cancellation or earplugs, and the participants were not an autism-specific sample. It therefore cannot establish that Sona is better than existing tools or that it is suitable for autistic airport travellers.

What this means for my project

This paper changes my thinking in two useful ways.

First, it makes preserving orientation while reducing sensory demand feel like a much clearer design principle. Sensory support should not automatically mean removing the user from the environment. The response could instead selectively reshape part of the environment while keeping important information accessible.

Second, it gives me a strong comparator for biosensing. Sona achieves responsive personalisation using environmental sensing and user preference alone. If I keep biosensing in the project, I need to demonstrate why physiological information adds something meaningful beyond this simpler architecture.

I am therefore keeping Sona as a strong reference for personalised, selective and user-controlled auditory accessibility, rather than as a model to copy directly. The most interesting question it raises for me is whether a future airport system could combine protected orientation cues, personalised sensory filtering and low-interaction support without making the traveller manage another complex interface at the moment they most need help.

Source

Huang, J. Z., Hicks, E., Sidharth, Hayes, G. R. and Jain, D. (2026). Sona: Personalized Soundscape Mediation to Support People with Sound Sensitivity. arXiv preprint, arXiv:2604.00447v2.

Key reading from my notes and analysis: system motivation and autism-related sound-sensitivity context, pp. 1–2; design goals and selective attenuation, pp. 3–5; interaction burden while encountering trigger sounds, p. 5; in-situ user evaluation and personalization findings, pp. 7–11; public-use, safety, privacy and limitations, pp. 11–14.