-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Detecting xruns in process callback #81
Comments
Why are you using stuff from Why not use write_midi_event() and get_buffer()? If there is no reason, can you please update your code example? |
Hi @mgeier. Sorry I should have posted a simplified example. I'm just calling if not xrun_set and last_frame_time - blocksize == self._before:
port.clear_buffer() At the moment, if the xrun callback is called or the frame times do not add up, I guess the last process callback resulted in an xrun and I don't clear the buffer. I want to know if that's the best way or if there's something simpler/more robust. Here's a standard version of the process callback: def process(self, frames: int) -> None:
expected_frame_time = self._client._last_frame_time - self._client.blocksize \
== self._before
if expected_frame_time and self._xrun.set():
self._port.clear_buffer()
if self._xrun.set():
self._xrun.clear()
self._before = self._client.last_frame_time
if self._buffer.read_space == 0:
return
data = self._buffer.read(self._buffer.read_space)
for i in range(0, self._buffer.read_space, 3):
self._port.write_midi_event(0, data[i : i + 3]) |
Ah, I see. You mainly want to avoid calling I'm not really familiar with the JACK MIDI API, but isn't this the reason why reserve_midi_event() exists? |
Coming back to your original question ... Since the xrun callback seems to run in a separate non-realtime thread, I guess using a I guess theoretically multiple process callbacks could be called before the xrun callback is invoked, but I don't know if this can happen in practice. It would be much better to have an API to get the xrun information directly from the process callback. I guess you would have the exact same question if you were implementing everything in C, right? I think you should ask at the JACK mailing list: https://jackaudio.org/community.html The problem might be that there are currently few subscribers because the list was moved and the subscriber list wasn't transferred: https://jackaudio.org/news/2019/12/16/mailing-list-and-rss-feed.html |
Thanks again @mgeier. Yep, I guess I'd have the same question regardless of language. I'll have a go at doing directly with the JACK API and asking the JACK people directly. then I'll report back. We've been using the code above for a couple of days and we haven't noticed dropped or duplicate MIDI events so maybe it's sufficient, if not optimal. |
Hi and thanks for the great library, been using it for years!
What's the best way to detect if the last process callback lead to an xrun? Here's my use case: I'm sending MIDI, which works 99% of the time. But when an xrun occurs, the MIDI events aren't sent to connected inputs and on the next process callback I clear the buffer and they're lost forever. Here's how I'm currently doing it:
I'm doing two things:
I'm comparing
last_frame_time - blocksize
to thelast_frame_time
on the previous process callback.Using the
set_xrun_callback
to set athreading.Event()
I'm not sure if I'm doing any of this correctly, just experimenting to see what works. I know you're not meant to use Python for realtime, but it's working too well to justify moving to C++.
Thanks.
The text was updated successfully, but these errors were encountered: