| Previous | Next |
| NS_E_UNEXPECTED_DISPLAY_SETTINGS | NS_E_INPUTSOURCE_PROBLEM |
NS_E_NO_AUDIODATA
How to interpret the code in a real encoding session
0xC00D1B89 is named NS_E_NO_AUDIODATA. Its practical scope is watchdog detects that an opened audio source has stopped delivering samples, which belongs to audio capture-device negotiation rather than to every part of Windows Media playback or Windows itself.
Mechanism and point of failure
For a live audio input, the source plug-in must open the selected endpoint and negotiate a WAVEFORMATEX-compatible stream before the source group can be prepared in a session that returns this result. Device ownership and format support are independent checks.
A device visible in the Encoder UI can still reject the requested format or be exclusively held by another process when the encoding graph is built in a session that returns this result. A typical reproduction is: a USB audio device remains enumerated after disconnect but produces no buffers. This makes the first result from the Encoder more valuable than a later generic message.
Reproduction matrix
| Field | What to preserve |
|---|---|
| Decisive values | last audio-sample timestamp, device state, mute/routing changes and capture callback errors |
| Producing object | device moniker and friendly name, process holding the endpoint, WAVEFORMATEX tag, channel count, samples per second, bits per sample, block alignment and source-plug-in HRESULT |
| Session correlation | the same source-group generation, audience index, object identity and callback sequence that produced this result |
| Lower-level evidence | the first COM, driver, file-system or codec HRESULT observed before the Encoder mapped the condition to this result |
| Controlled comparison | a known-good session that changes only the setting named in the no audiodata boundary |
Evidence matrix
| Observation | How to interpret it |
|---|---|
| Observation that supports it | The decisive evidence is last audio-sample timestamp, device state, mute/routing changes and capture callback errors. It confirms watchdog detects that an opened audio source has stopped delivering samples in the same object generation. |
| Observation that points to an earlier failure | The recorded values satisfy the no audiodata rule, but a source, driver, COM activation or file operation returns a different HRESULT first. |
| Observation that points to a later failure | The Encoder passes this boundary (watchdog detects that an opened audio source has stopped delivering samples), but a codec, archive or broadcast sink then fails in a subsequent stage. |
| Verification after correction | Apply this isolated change: restore sample delivery from the selected endpoint and restart the source graph. The original no audiodata call should then advance past the same checkpoint. |
The operational impact of it is limited to the audio capture-device negotiation transition that owns watchdog detects that an opened audio source has stopped delivering samples. In the representative case where a USB audio device remains enumerated after disconnect but produces no buffers, keep the first failing call and its object identity so a later wrapper cannot replace the no audiodata evidence.
Minimal experiment
- Record
0xC00D1B89, it, the Encoder version and the exact API call or property access that returned it. - Export the current
.wmeor.prxconfiguration, then capture last audio-sample timestamp, device state, mute/routing changes and capture callback errors. - verify the audio capture-device negotiation precondition without changing the source, profile and output sink at the same time.
- Run one controlled comparison in which only this condition changes: restore sample delivery from the selected endpoint and restart the source graph.
- After the change, recreate the affected Encoder object rather than assuming the existing graph discarded its earlier no audiodata state.
Do not collapse these results together
| Result | Why it is a different boundary |
|---|---|
NS_E_AUDIODEVICE_BADFORMAT | negotiation of the requested WAVEFORMATEX with the audio capture device |
NS_E_AUDIODEVICE_UNEXPECTED | audio capture initialization after device discovery but outside a recognized busy or format rejection |
NS_E_AUDIODEVICE_BUSY | exclusive opening of the selected audio capture endpoint |
What to change—and what to leave alone
Change the smallest responsible precondition: restore sample delivery from the selected endpoint and restart the source graph. While retesting it, keep all unrelated source, audience and output values fixed until the same call is repeated.
Do not change the audio driver, sample rate and source plug-in simultaneously; first preserve the exact WAVEFORMATEX and the first open or negotiation HRESULT in a session that returns it.
Authoritative documentation
- Retrieving the configured encoder input.
- WAVEFORMATEX structure.
- Preparing a source group for encoding.
- WMEncoder.Start.
Looking for a different code? Search another status or error code.