Hmmm... in the jack backend there is no ring buffer. Jack just dumps a
large buffer from the audio callback and notifies the Pd audio thread,
which consumes the buffer in chunks of 64 samples.
I think you could just copy the port audio backend implementation with
its lock-free ringbuffer. This would also solve the socket polling issue :-)
Maybe the "polling scheduler" part could even be moved out of
"s_audio_pa.c" and shared with the jack backend.
---
On the other hand, I've been wondering if the "Delay" parameter is
actually necessary at all. As the Jack backend demonstrates, you can
just as well use a larger hardware buffer size. The only advantages I
see are:
* latency can be controlled at a finer granularity; hardware buffer
sizes are usually power-of-2s, so there's no step between 11.6 ms (512
samples) and 23.3 ms (1024 samples), for example.
* the latency can be set arbitrarily high while the hardware buffer size
is limited (often 1024 samples)
Unfortunately, very few people actually seem to understand the
difference between the "block size" (= hardware buffer size) and the
"Delay" in Pd's audio settings and how they interact... But maybe that's
just because of the lack of documentation. After all, I only understood
it after reading the code :-)
Christof
On 24.07.2021 03:05, Miller Puckette wrote:
Aha.. I've been meaning to look at why jack doesn't respond to audio latency
setting... I think it needs fooling with.
cheers
M
On Sat, Jul 24, 2021 at 01:01:43AM +0200, Christof Ressi wrote:
Hi Miller,
As I understand it, when Pd is idle (finishes a 64-sample block and can't yet
crunch the following one), then it goes back and re-checks for network or
GUI input, and keeps doing that until either there isn't anything to read or
else the next block becomes runnable.
AFAICT, that's true for pa_send_dacs(), but not for jack_send_dacs(). The
former calls sys_microsleep() in a loop, so it will only actually sleep if
there are no more sockets to read; the latter immediately blocks on a
condition variable if the buffer is not available.
I need to add some sort of poll-it-again functionality to libpd but haven't
figured out what shape it should take yet.
Since libpd manages the audio callback, the client can simply call
sys_pollgui() as often as they want/need. I don't think that you actually
have to add anything. Maybe just add a more fitting alias, like sys_poll()
or sys_pollsockets()? sys_pollgui() is really a misnomer...
Christof
So this is a simple throttling
mechanism. (And it's not necessary to put this on another thread).
However, in the context of libpd thre's no concept of "idle" and so in that
setup there's only one network read per block.
And yes, this can lead to delays since the Macintosh helpfully stores unread
packets until the reading process gets around to realding them. I think that
also only happens in the context of libpd.
I need to add some sort of poll-it-again functionality to libpd but haven't
figured out what shape it should take yet.
Miller
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
