ALSA Pulse plugin returns -EIO from snd_pcm_avail_delay() in case of -PA_ERR_NODATA

[argothiel]

Environment

• Ubuntu 26.04 under WSL2 / WSLg
• libasound2-plugins 1.2.12-2build1
• PulseAudio server available through WSLg

Problem

Immediately after configuring a playback PCM opened through the ALSA pulse plugin, snd_pcm_avail_delay() returns -EIO. This seems to be an issue with pulse_delay() which calls pa_stream_get_latency(). PulseAudio documents that this function returns -PA_ERR_NODATA when timing information is not available yet. The ALSA Pulse plugin compares the result against positive PA_ERR_NODATA; it therefore treats that temporary condition as an unrelated failure and returns -EIO:

• ALSA Pulse plugin comparison:
  

  alsa-plugins/pulse/pcm_pulse.c

  Lines 397 to 404 in ffc8b90

  	err = pa_stream_get_latency(pcm->stream, &lat, NULL);
  	if (err) {
  	if (err != PA_ERR_NODATA) {
  	err = -EIO;
  	goto finish;
  	}
  	} else
  	break;

• PulseAudio pa_stream_get_latency() documentation:
  https://github.com/pulseaudio/pulseaudio/blob/77d25a1e613095bdf87a1d13b65e7c330565077a/src/pulse/stream.h#L725-L726
• The same issue has been fixed in the shairport-sync version:
  audio_pa.c: pa_delay, return "No latency data yet" on PA_ERR_NODATA mikebrady/shairport-sync#2119

Reproducer

#include <alsa/asoundlib.h>
#include <assert.h>
#include <stdio.h>

int main(void)
{
    snd_pcm_t *pcm;
    snd_pcm_sframes_t avail, delay;
    int err;

    err = snd_pcm_open(&pcm, "pulse", SND_PCM_STREAM_PLAYBACK, 0);
    assert(err == 0);

    err = snd_pcm_set_params(
        pcm,
        SND_PCM_FORMAT_FLOAT_LE,
        SND_PCM_ACCESS_RW_INTERLEAVED,
        2,
        48000,
        1,
        20000);
    assert(err == 0);

    err = snd_pcm_avail_delay(pcm, &avail, &delay);
    printf("snd_pcm_avail_delay: %s (%d)\n", snd_strerror(err), err);

    snd_pcm_close(pcm);
    return err < 0;
}

Build and run:

cc main.c -lasound && ./a.out

Actual result

snd_pcm_avail_delay: Input/output error (-5)

Expected result

snd_pcm_avail_delay() should wait until PulseAudio timing information is available, then return the available-frame and delay values.

[dblumenau]

Independent confirmation on Ubuntu 24.04 under WSL2/WSLg, with Codex CLI 0.159.3, CPAL 0.18.2, and libasound2-plugins 1.2.7.1-1ubuntu5.

Codex voice sometimes worked for several spoken turns, then failed with “voice audio session stopped unexpectedly”; other attempts failed shortly after starting. Ordinary PulseAudio/ALSA recording and playback worked. A separate CPAL duplex probe also passed, so those checks alone did not expose the failure.

I traced the actual bundled Codex voice helper under GDB and caught its CPAL device-error callback. The error was:

ALSA function 'snd_pcm_avail_delay' failed with error 'I/O error (5)'

The caller was cpal::host::alsa::output_stream_worker, identifying the speaker/output stream. Codex recorded phase=Some(Device) exit_code=Some(37).

I independently found the incorrect PA_ERR_NODATA check and built a local copy of the PulseAudio PCM plugin. The change actually tested here was:

- if (err != PA_ERR_NODATA) {
+ if (pa_context_errno(pcm->p->context) != PA_ERR_NODATA) {

The plugin was selected through a user ALSA configuration override:

pcm_type.pulse {
    lib "/absolute/path/to/patched/libasound_module_pcm_pulse.so"
}

With that plugin active, the same Codex session accepted a synthetic spoken test and replied, then transcribed the physical microphone and responded normally. This was done without another WSL restart. Only new audio streams were opened.

After finding this existing issue, I agree that the direct negative-return-code comparison proposed in #67 is the smaller upstream correction:

- if (err != PA_ERR_NODATA) {
+ if (err != -PA_ERR_NODATA) {

The exact return value from pa_stream_get_latency() was not captured in my debugger run; the verified observations are the output callback's ALSA EIO and successful voice operation after the context-error-check variant. This adds a local confirmation on another plugin version, rather than establishing that every Codex Device/37 failure has this cause.

Related application report: openai/codex#47370