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
Would Queue be an easier thing to use in python? Not sure what the timing implications are, but i think one can get a nonblocking version of it.
I know we have it (and my project actually needs it since it uses ringbuffers in the C portion), but Queue might be a better choice if you want to move structured data.
but i think one can get a nonblocking version of it
I think that's the point, as far as I understand, Python's queue module uses locking.
Where would we get a non-blocking queue?
Queue might be a better choice if you want to move structured data.
Sure, but that's why I think it would be a good usage example, because there we could show how to use a RingBuffer with data items which are larger than a byte.
Sure, but that's why I think it would be a good usage example, because there we could show how to use a RingBuffer with data items which are larger than a byte.
Well, I implemented both examples for you.
As I predicted, the ringbuffer one is a lot bigger and uglier. I don't think there are many advantages on using that one (besides the fact that maybe it has a leaner implementation? but who cares, we're using python anyway). I also had to use struct to pack and unpack the time offsets and lengths for the packets.
The ringbuffer based branch also has a couple of other fixes/commits I needed.
Ringbuffers might be better suited to move audio data around (since individual samples don't really need to be time labeled) and everything (bigger chunks too) can be kept in buffer form. Then pure python data objects doesn't have to go through the ringbuffer.
Something where the main thread reads audio samples from a file then passes them to the process thread for sending to jack might be a good use of it.
Thanks for the example implementations, that's really interesting!
Python's built-in Queue uses locks, right?
If yes, it's as bad as directly using print() in the process callback, so we don't gain anything with Queue.
It is indeed much more complicated than I imagined to use the jack.RingBuffer for this.
Due to an apparent lack of a blocking "read" function, we cannot wait on the RingBuffer (on the non-realtime side), which makes the code even worse.
In the light of this I think it's best to just keep the print() calls as they are and add a comment that this is actually bad practice and shouldn't be used in real code.
In the future we might find a more meaningful example which sends audio data over a RingBuffer.
Python's built-in Queue uses locks, right?
If yes, it's as bad as directly using print() in the process callback, so we don't gain anything with Queue.
It probably does use locks, but it's non-blocking (the stuff inside process shouldn't wait for a long time all the sudden). So it should be fine.
I do think it's better to use Queue than no Queue and just print.
I had a quick look at the CPython source, and Queue indeed uses a lock (named self.mutex): https://hg.python.org/cpython/file/3.4/Lib/queue.py#l38 Queue.put_nowait() acquires this lock, therefore it should not be used in the process callback.
The problem is that using Queue may look like a proper solution but it isn't.
I'd prefer to either show an actual solution (which turned out to be too complicated with jack.RingBuffer) or show an obviously bad (but very simple) solution and mention this fact in a comment.
Unless we find a simple way to do the former, we should do the latter.
I am worried about it, but there is nothing I can do about it (except probably trying the GIL-less STM PyPy).
I'm worried about Queue because it might give a false sense of safety.
The example doesn't get any more useful/readable/understandable/safe/beautiful/... by using a Queue instead of naively using print().
To make the limitations explicit, I created PR #18, what do you think about it?
Activity
amstan commentedon May 23, 2015
Would Queue be an easier thing to use in python? Not sure what the timing implications are, but i think one can get a nonblocking version of it.
I know we have it (and my project actually needs it since it uses ringbuffers in the C portion), but Queue might be a better choice if you want to move structured data.
mgeier commentedon May 24, 2015
I think that's the point, as far as I understand, Python's queue module uses locking.
Where would we get a non-blocking queue?
Sure, but that's why I think it would be a good usage example, because there we could show how to use a
RingBufferwith data items which are larger than a byte.BTW, I don't know yet how to do that ...
Used a jack ringbuffer for the midi_monitor example
Used a Queue into midi_monitor example
amstan commentedon May 25, 2015
Well, I implemented both examples for you.
As I predicted, the ringbuffer one is a lot bigger and uglier. I don't think there are many advantages on using that one (besides the fact that maybe it has a leaner implementation? but who cares, we're using python anyway). I also had to use struct to pack and unpack the time offsets and lengths for the packets.
The ringbuffer based branch also has a couple of other fixes/commits I needed.
amstan commentedon May 25, 2015
Ringbuffers might be better suited to move audio data around (since individual samples don't really need to be time labeled) and everything (bigger chunks too) can be kept in buffer form. Then pure python data objects doesn't have to go through the ringbuffer.
Something where the main thread reads audio samples from a file then passes them to the process thread for sending to jack might be a good use of it.
mgeier commentedon May 27, 2015
Thanks for the example implementations, that's really interesting!
Python's built-in
Queueuses locks, right?If yes, it's as bad as directly using
print()in the process callback, so we don't gain anything withQueue.It is indeed much more complicated than I imagined to use the
jack.RingBufferfor this.Due to an apparent lack of a blocking "read" function, we cannot wait on the
RingBuffer(on the non-realtime side), which makes the code even worse.In the light of this I think it's best to just keep the
print()calls as they are and add a comment that this is actually bad practice and shouldn't be used in real code.In the future we might find a more meaningful example which sends audio data over a
RingBuffer.amstan commentedon May 27, 2015
It probably does use locks, but it's non-blocking (the stuff inside process shouldn't wait for a long time all the sudden). So it should be fine.
I do think it's better to use Queue than no Queue and just print.
mgeier commentedon May 28, 2015
I had a quick look at the CPython source, and
Queueindeed uses a lock (namedself.mutex): https://hg.python.org/cpython/file/3.4/Lib/queue.py#l38Queue.put_nowait()acquires this lock, therefore it should not be used in the process callback.The problem is that using
Queuemay look like a proper solution but it isn't.I'd prefer to either show an actual solution (which turned out to be too complicated with
jack.RingBuffer) or show an obviously bad (but very simple) solution and mention this fact in a comment.Unless we find a simple way to do the former, we should do the latter.
amstan commentedon May 28, 2015
process() itself also aquires the GIL. Why are you not worried about that, but are worried about Queue?
mgeier commentedon May 29, 2015
I am worried about it, but there is nothing I can do about it (except probably trying the GIL-less STM PyPy).
I'm worried about
Queuebecause it might give a false sense of safety.The example doesn't get any more useful/readable/understandable/safe/beautiful/... by using a
Queueinstead of naively usingprint().To make the limitations explicit, I created PR #18, what do you think about it?