Can you provide a backtrace for all threads in the SDL audio player? Apparently one thread calls pa_threaded_mainloop_stop(), and that will wait for the thread where the libpulse mainloop is running to quit. I don't think the mainloop thread should block on anything, but maybe there's some application callback doing something that it shouldn't do.

Is this audio player available somewhere in case I want to try to reproduce?

Unfortunately the player is closed source. However I managed to reduce it to the following piece of code:

void* check_audio_freeze(void *_) {
  if(SDL_Init(SDL_INIT_AUDIO) < 0) {
    printf("SDL_Init: %s\n", SDL_GetError());
    return NULL;
  }
  int flags = MIX_INIT_OGG;
  int initted = Mix_Init(flags);

  if((initted&flags) != flags) {
    goto sdl_deinit;
  }

  if(Mix_OpenAudio(44100, AUDIO_S16, 2, 512) < 0) {
    printf("Mix_OpenAudio: %s\n", Mix_GetError());
    goto mix_deinit;
  }

  Mix_AllocateChannels(64);

  Mix_CloseAudio();
 mix_deinit:
  Mix_Quit();
 sdl_deinit:
  SDL_Quit();
  return NULL;
}

Once Pulseaudio has frozen, even new executables (such as the one above) will freeze when trying to deinitialize the sound system.

I also forgot to mention that this is a semi-embedded Linux distribution that runs PA in system mode. I have tried to reproduce this issue on a stock distro but thus far has been unsuccessfull (but the bug happens very rarely even on the custom distro).

So it's really the pulseaudio daemon that is freezing? You said in the initial report that the freeze happens inside pulseaudio, but "SDL's deinit calls into PA, which does a pthread_join that never returns" made me think that by pulseaudio you're probably referring to libpulse in the application process.

Can you get a backtrace from the frozen daemon?

I'll try reproducing, but based on your reproducibility comment that will probably be futile.

1000 runs of the code didn't cause any freezing.

This bug is nasty because it most likely boils down to a race condition that happens very rarely. This is what we came up with:

- machine is booted
- pulseaudio starts up in system mode
- in some circumstances PA's startup is delayed, and the program using SDL audio starts up and grabs the sound card before PA is fully running
- PA is now running, and the first application is using SDL audio, but it is using Alsa directly
- programs started after PA starts try to connect to PA, succeed, and send their sound data there but PA can't play it because the sound card is held by the first launched application
- when closing one of the applications that are started afterwards, they get hung in the method described above

We tried delaying the startup with systemd rules so that the application is only started after PA's control socket appears. This did not work. The only thing that did work was creating a startup application that tries to open SDL audio, forcing it to use PA and delay starting any other program until it has successfully opened a PA audio connection.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/203.