a live audio destination corresponds to an audio device that exists
Check id audio-sink-vs-device-list
What an ordinary browser yields
Under a Windows or macOS claim, a running audio destination with output channels is accompanied by at least one enumerated media device. Any other platform, a destination with no channels, or an unavailable API all decline.
What a detector infers
A resource oracle, and deliberately a different resource from the voice list. The two fire together on a headless container, but they are independent surfaces and a product can patch one without the other — CloakBrowser Pro's Chromium 150 notes advertise closer alignment with a real Chrome install across speech and language profiles, which is work on the speech pipeline specifically. What makes this row self-referential rather than a claim about hardware is that the contradiction is not zero devices, which is an ordinary state for a server. It is zero devices WHILE the audio graph is running with real output channels. Chromium substitutes a dummy sink when no audio device exists, so the AudioContext still reports a running destination with two channels; the graph is feeding nothing. Measured, stock Chrome headed on a real Windows desktop reports two devices (one audioinput, one audiooutput) alongside a two-channel destination at 48000 Hz, while a headless Linux container reports zero devices alongside the same two-channel destination at 44100 Hz. enumerateDevices is the right surface for this because permission gates device LABELS and not their existence: a browser with no camera or microphone permission still reports that the devices are there, with empty label strings, so an empty ARRAY means the device list itself is empty rather than redacted. The row asserts only under a Windows or macOS claim, the same scoping the speech row uses, because a headless Linux server genuinely has no audio device and that is an honest state rather than a disguise. Severity warn rather than critical for the same reason it is on the speech row: stripped Windows images and VDI templates without audio hardware are real, so this is implausible rather than impossible.
How to resolve it
The device list and the audio graph are both answered by the host's audio stack, so they cannot honestly disagree. Chromium's dummy sink keeps an AudioContext running when no output device exists and leaves the device list empty, and that pairing is what a container looks like from the inside. There is nothing to patch at the JavaScript layer that would not simply move the incoherence: give the machine a real audio device, or present the operating system it is actually running on rather than a desktop that would have one.
Read in the wild by
CloakBrowser Pro releases
Not a sighting of this row firing, but of the surface being actively worked: the Chromium 150 release notes advertise closer alignment with a real Chrome install across speech and language profiles. That is the neighbouring resource — the voice list — which is why this row reads the audio DEVICE list instead. A build that has patched the speech pipeline has not thereby patched enumerateDevices.
CloakBrowser Pro Chromium 150 release notes, speech and language profile alignment.
CloakBrowser Pro releasesClearcote (measured)
Measured while establishing ground truth for this row rather than as a vendor sighting. A headless Linux container reports zero media devices while its AudioContext runs a two-channel destination — Chromium's dummy sink standing in for hardware that is not present. The same probe on a real Windows desktop reports two devices alongside an identical destination.
real Windows headed Chrome: devices 2 (audioinput 1, audiooutput 1), maxChannelCount 2, 48000 Hz, state running. Headless Linux container: devices 0, maxChannelCount 2, 44100 Hz, state running.
clearcotelabs.com/auditEvery attribution traces to a published artifact. See the sources and their limits.
Nearby checks in Environment & locale
- the analyser byte spectrum is the defined quantisation of its float spectrum
audio-analyser-float-vs-byteAn AnalyserNode publishes the same spectrum twice. getFloatFrequencyData returns decibels, and getByteFrequencyData returns that spectrum… - speech synthesis voices (host OS speech engine)
speech-voicesspeechSynthesis.getVoices() enumerates the host operating system's speech engine — a resource stealth stacks essentially never touch, which… - the voice list arrives the way Chrome delivers it
speech-voices-async-pathspeech-voices reads WHAT is in the voice list. This reads HOW the list arrived, which is a separate fact and survives a roster whose every… - an OS that ships a speech synthesiser enumerates at least one voice
speech-voices-vs-platformThe plain speech-voices readout above refuses to score an empty list, and as written it is right to: Chrome does not build the voice list in… - WebSQL (openDatabase) is absent for Chrome ≥ 119
opendatabase-removedWebSQL was removed from Chrome in version 119, so window.openDatabase should not exist on any newer Chromium. - BatteryManager fields satisfy the spec's mutual-exclusion invariants
battery-spec-invariantsThe probe calls navigator.getBattery() once and records four fields together: level, charging, chargingTime, dischargingTime. - enumerateDevices exposes audiooutput on a Chromium claim
media-kinds-vs-engineThe probe calls navigator.mediaDevices.enumerateDevices() and keeps only each entry's .kind, sorted — never labels or deviceIds, which is… - mediaCapabilities and canPlayType agree about the same codec
mediacapabilities-vs-canplaytypeTwo different APIs answer from the same platform decoder registry.
Clearcote is a browser built for fingerprint coherence
It is a Chromium fork, maintained by the same people who wrote this reference. It ships as a compiled browser rather than as a stealth script injected into someone else's — which is a description of how it is built, and is not an argument about how it behaves on this check.
This audit takes no position on how Clearcote scores on Environment & locale checks, on this one, or anywhere else. It has no baseline corpus of other people's fingerprints to rank you against and no vendor scoreboard — nearly every check is self-referential, asking one browser the same question through two independent APIs and reporting whether both answers can be true at once. It runs identically on any browser, including ours. Run it on yours and read the result yourself.
See the other checks in Environment & locale — the family audio-sink-vs-device-list belongs to.