You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, quite a few operations of [mp3cast~] might block Pd and thus cause audio-drop outs. Those drop-outs affect only the local DSP processing, but not the streamed (or much less so), since the buffers of the streaming are comparatively large. In some use cases, the blocking nature of [mp3cast~] doesn't cause much harm. In others, especially when using live input, or when playing sound locally with the same instance of Pd, the drop-outs are noticeable.
There are other means to decouple the Pd process from the streaming, for instance, by routing Pd's audio output through JACK to an Icecast source client, like ffmpeg. It's open for debate how much [mp3cast~] would benefit from being truly non-blocking. I am probably not going to implement it soon, but I'm certainly open for a discussion.
The text was updated successfully, but these errors were encountered:
Currently, quite a few operations of [mp3cast~] might block Pd and thus cause audio-drop outs. Those drop-outs affect only the local DSP processing, but not the streamed (or much less so), since the buffers of the streaming are comparatively large. In some use cases, the blocking nature of [mp3cast~] doesn't cause much harm. In others, especially when using live input, or when playing sound locally with the same instance of Pd, the drop-outs are noticeable.
There are other means to decouple the Pd process from the streaming, for instance, by routing Pd's audio output through JACK to an Icecast source client, like ffmpeg. It's open for debate how much [mp3cast~] would benefit from being truly non-blocking. I am probably not going to implement it soon, but I'm certainly open for a discussion.
The text was updated successfully, but these errors were encountered: