Most modules implement the IO thread event loop with pa_rtpoll, but module-tunnel-sink/source-new implement the event loop with pa_mainloop. module-rtp-recv assumes that the IO thread event loop is implemented with pa_rtpoll, so using module-rtp-recv with module-tunnel-sink-new results in a crash. I think the interaction with the event loop in module-rtp-recv and elsewhere should be done through pa_mainloop_api instead of accessing the underlying implementation directly. This requires a pa_mainloop_api implementation based on pa_rtpoll.
(In reply to Tanu Kaskinen from comment #0) > I think the interaction with the event loop in module-rtp-recv and elsewhere > should be done through pa_mainloop_api instead of accessing the underlying > implementation directly. This requires a pa_mainloop_api implementation > based on pa_rtpoll. The intention behind the quoted paragraph was that we'd keep using pa_mainloop in the tunnel modules and pa_rtpoll elsewhere. When I started to work on this, I decided to go with a different approach: I changed the event loop implementation in the tunnel modules to pa_rtpoll. That still required me to implement pa_mainloop_api on top of pa_rtpoll, because libpulse requires pa_mainloop_api. I've sent patches to the mailing list: http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/22563
A band-aid patch that fixes some crashes has been applied: https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=0fe98ecf5a99e03a300b98e3f71401364ebb115e As the commit message says, it's not a complete fix.
-- 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/293.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.