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
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
>
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 t
On Fri, Jul 23, 2021 at 11:59:26PM +0200, Christof Ressi wrote:
> On 23.07.2021 23:11, Roman Haefeli wrote:
>
> > On Fri, 2021-07-23 at 21:52 +0200, Christof Ressi wrote:
> > > When we overhauled the networking code, I noticed that the TCP and
> > > UDP functions would both read up to N bytes (w
On 23.07.2021 23:11, Roman Haefeli wrote:
On Fri, 2021-07-23 at 21:52 +0200, Christof Ressi wrote:
When we overhauled the networking code, I noticed that the TCP and
UDP functions would both read up to N bytes (where N is currently
4096) in a single recv() call. With TCP the buffer can contain
On Fri, 2021-07-23 at 21:52 +0200, Christof Ressi wrote:
> When we overhauled the networking code, I noticed that the TCP and
> UDP functions would both read up to N bytes (where N is currently
> 4096) in a single recv() call. With TCP the buffer can contain
> several FUDI (or other) messages, but
Those only read a single UDP packet in the poll function.
OK, good to know. I'm glad I was not way off with my assumption. Would
it be technically possible for the reader thread to read as many
packets as available during a single tick?
Generally, it's not a good idea to read as many packets as
On Fri, 2021-07-23 at 15:09 +0200, Christof Ressi wrote:
> I assume you're using [iemnet] or [mrpeach] objects?
Yes, [iemnet/udpclient]. But it seems the same applies to [netsend]
(when receiving).
> Those only read a single UDP packet in the poll function.
OK, good to know. I'm glad I was not
Hi,
I assume you're using [iemnet] or [mrpeach] objects? Those only read a
single UDP packet in the poll function.
[netreceive], on the other hand, reads several packets up to a certain
throttle limit.
---
Now to the actual problem:
The poll functions are called in sys_domicrosleep(). sys
Hi all,
We experience "unexpected" latency with our software tpf-client [1] on
macOS. When using JACK as audio-backend and using a blocksize [2] of
64, latency grows over time, growing whenever there are dropped
packets.
The issue appears only when all three criteria are met:
* Pd is running
10 matches
Mail list logo
