search

adamrehn / pixel-streaming-linux

Issue tracker repository for Pixel Streaming for Linux
https://adamrehn.com/articles/pixel-streaming-in-linux-containers/
22 stars 7 forks source link

WebRTC crashes initialising audio engine in a container #35

Closed lukehb closed 3 years ago

lukehb commented 3 years ago

Many users are getting errors initialising WebRTC inside containers when using our Pixel Streaming for Linux 4.25 in containers.

User's who run into this problem typically appear to have a stack trace that looks something like this:

0x00007f461d18dfb7 libc.so.6!gsignal(+0xc7)
0x00007f461d18f921 libc.so.6!abort(+0x140)
0x000000000768d778 MyProject2!rtc::webrtc_checks_impl::FatalLog(char const*, int, char const*, rtc::webrtc_checks_impl::CheckArgType const*, ...)()
0x0000000007954de0 MyProject2!webrtc::adm_helpers::Init(webrtc::AudioDeviceModule*)()
0x000000000794ac2e MyProject2!cricket::WebRtcVoiceEngine::Init()()
0x000000000792d29d MyProject2!cricket::CompositeMediaEngine<cricket::WebRtcVoiceEngine, cricket::WebRtcVideoEngine>::Init()()
0x0000000007a17ce6 MyProject2!rtc::FunctorMessageHandler<bool, cricket::ChannelManager::Init()::$_2>::OnMessage(rtc::Message*)()
0x000000000769d4f5 MyProject2!rtc::MessageQueue::Dispatch(rtc::Message*)()
0x00000000076a70e8 MyProject2!rtc::Thread::ReceiveSendsFromThread(rtc::Thread const*)()
0x000000000769c7d6 MyProject2!rtc::MessageQueue::Get(rtc::Message*, int, bool)()
0x00000000076a6b88 MyProject2!rtc::Thread::Run()()
0x00000000076a6a7a MyProject2!rtc::Thread::PreRun(void*)()
0x00007f461f9626db libpthread.so.0!UnknownFunction(0x76da)
0x00007f461d27071f libc.so.6!clone(+0x3e)
[2021.02.19-21.35.30:551][  0]LogExit: Executing StaticShutdownAfterError

We believe there is a way to rebuild the WebRTC binaries to disable the need for Alsa. We will track that work here.

In addition to investigating alternate ways to build WebRTC, we will work on providing a run-time container image that sets up a pulse audio server in the container for you. You can track this progress at: https://github.com/adamrehn/ue4-runtime

Some workarounds in the meantime:

  1. Bind-mounting the host system's pulse audio into the container, like so: sudo docker run --rm --gpus=all -v ${XDG_RUNTIME_DIR}/pulse/native:${XDG_RUNTIME_DIR}/pulse/native --network=host your-project-here -PixelStreamingIP=127.0.0.1 -PixelStreamingPort=8888

  2. Disable WebRTC's audio entirely by passing in a -NOAUDIO flag.

adamrehn commented 3 years ago

I have now determined that this was a symptom of the manner in which the ue4-runtime container images were configured. Up until now, I'd configured the container to expect a PulseAudio socket bind-mounted from the host system if audio output was required, which was useful when debugging audio (since you could hear the output on the host system) but prevented audio from functioning correctly when the bind-mount was missing. I have now updated the ue4-runtime Dockerfiles to automatically spawn a PulseAudio daemon inside the container as needed, and added a new set of variants tagged with the suffix -hostaudio that provide the old behaviour for use cases that need it. Simply pulling the new version of your desired ue4-runtime image tag and rebuilding your containers will fix this problem for Pixel Streaming applications and allow audio output to function correctly.