Killing/restarting pulseaudio server causes RtAudio to run in fast-forward

[nyanpasu64]

I'm using a slightly modified version of 32df948.

When I start RtAudio in PulseAudio mode, then run killall pulseaudio in a terminal window, then RtAudio apps run the audio callback in fast-forward, discarding all audio data synthesized and immediately calling it again for more audio. This causes the audio thread to eat an entire CPU core.

(Why do I do it? On my machine, my 3.5mm headphone jack sometimes disappears from PulseAudio's output list, and restarting PulseAudio fixes the issue.)

Is it possible to change RtAudio to not burn a full CPU core? (I don't know how to handle errors though, whether to take the nuclear option and throw an uncaught exception like unplugging a headphone jack on Windows, or to stop the audio thread only, or something else. I hear that RtAudio's error handling is in flux, with discussions over how to redesign it.)

[garyscavone]

I don’t have any experience with the PulseAudio API but it seems that some sort of callback could be registered to be informed about an impending shutdown of the audio server and that RtAudio could then deal with that situation in a more robust way? On Jun 21, 2021, at 6:55 PM, nyanpasu64 ***@***.******@***.***>> wrote: I'm using a slightly modified version of 32df948<32df948>. When I start RtAudio in PulseAudio mode, then run killall pulseaudio in a terminal window, then RtAudio apps run the audio callback in fast-forward, discarding all audio data synthesized and immediately calling it again for more audio. This causes the audio thread to eat an entire CPU core. (Why do I do it? On my machine, my 3.5mm headphone jack sometimes disappears from PulseAudio's output list, and restarting PulseAudio fixes the issue.) Is it possible to change RtAudio to not burn a full CPU core? (I don't know how to handle errors though, whether to take the nuclear option and throw an uncaught exception like unplugging a headphone jack on Windows, or to stop the audio thread only, or something else. I hear that RtAudio's error handling is in flux, with discussions over how to redesign it.) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#299>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABJYDJIJC2ICGH7NYG6JMV3TT67PFANCNFSM47CQKXMQ>. Gary Scavone Computational Acoustic Modeling Lab - www.music.mcgill.ca/caml/<http://www.music.mcgill.ca/caml/> Professor, Music Technology Area Coordinator Schulich School of Music, McGill University (514) 398-4535, x-089834