i just came across a difference in the way that Ardour behaves between v6.6 (on Debian) vs v6.9 (on Ubuntu). Ardour is now warning about ambiguous latency on some non-connected output channels. that’s fine, helpful to know but it’s normal for the way i use Ardour and i’d like to shut off the ever-climbing number of errors in the log.
here’s a picture that will hopefully tell the tale. the error log is pointing at those 8 channels that aren’t connected to an outgoing Jacktrip session. the one connected session (to me, good old Player1) is fine. those extra channels are waiting for additional players to be connected, at which point a little script of mine will circle around and connect them up.
is that Jack throwing those errors? or Ardour. if it’s Jack, i’ve got a different puzzler.
one approach i suppose would be to connect all the unused outputs to a dummy channel and then disconnect/reconnect them. or, is there a more elegant way to handle this situation?
ah. here’s a little more info – this only happens when somebody’s connected through Jacktrip. here’s a link to a very short (22 second) screen grab to show what’s going on. the exciting plot is… i’m not connected to the server, then i’m connected through jacktrip, then i’m not again. thrilling, no??
It looks like you connect Ardour’s output to to multiple targets with different playback latency. So Ardour (or any JACK client) cannot know what to align to. There is no unique time position for playback.
However it is odd that one of the player ports apparently reports zero latency.
Can you run jack_lsp --port-latency for both cases (with and without jacktrip connection), and post the output?
–
Then again, unless you record overdubs, or require correct alignment of audio and timecode (video etc), you can ignore this warning.
Ah! Glad to hear you confirm my hope that these can be ignored. Which gets me back to my question about whether there’s a way to quiet down the error window, which grows about 5 entries per second.
the summary: the older versions of the code(s) don’t see the latency that the newer codes do. the terminal log of the Ubuntu “connected” session was also throwing tons of this error message…
restarting Session::update_latency. # of send changes: 1 iteration: 1
It occurred to me to run a few more tests, since another piece of code that changed was Jacktrip (from 1.5.1 to 1.5.3). I built a new server and ran the ‘connected’ scenario for versions 1.4.2, 1.5.1 and 1.5.3 of Jacktrip. They all behaved the same. Dang.
I watched the errors in the terminal window more carefully and noticed that they’re happening about once a second. It’s ever-so-slightly varying. Here’s another in the series of thrilling screen-shot videos. Very short, just long enough to show the pace that they’re happening.
Those messages are normal, when aux-sends are used, Ardour will first have to calculate latency of internal sends and the do the JACK latency update. Those restarting Session::update_latency messages are not errors, just debug-messages. – I thought only debug-versions of Ardour print it, but it looks like we forgot to remove it from optimized builds.
Anyway it looks like some JACK app periodically performs JACK latency callbacks. Usually they only happen when connections are changed.
Maybe it’s jack-trip that announces a new playback latency from time to time. That’d be odd though, the playback stream will not be continuous in that case.
It’s also worrying that different minor versions of JACK produce different results.
Anyway the problem seems to be that Ardour introduces a 16 sample capture latency, while the same port is connected to some other jack-client that cannot handle it and forces a zero latency: [min=0 max=16].
I’m glad those messages are there. It allowed me to provide one more clue. The one-second periodicity bugged me all afternoon, so I stood up another server and used them to find the source, but not the solution. I am calling the following command once a second in a script that is monitoring who is connected via Jacktrip. Here’s the command.
jack_lsp -c send
Each time it’s fired it generates two of the ‘restarting session’ messages. It also triggers another group of errors in the log window. Here’s the result of one firing:
2022-04-07T22:15:23 [WARNING]: Ambiguous latency for port ‘-a Player1/audio_out 1’ (0, 640)
2022-04-07T22:15:23 [WARNING]: Ambiguous latency for port ‘-a Player1/audio_out 2’ (0, 640)
2022-04-07T22:15:23 [WARNING]: Ambiguous latency for port ‘-a Player2/audio_out 1’ (0, 640)
2022-04-07T22:15:23 [WARNING]: Ambiguous latency for port ‘-a Player2/audio_out 2’ (0, 640)
2022-04-07T22:15:23 [WARNING]: Ambiguous latency for port ‘-a Player3/audio_out 1’ (0, 640)
2022-04-07T22:15:23 [WARNING]: Ambiguous latency for port ‘-a Player3/audio_out 2’ (0, 640)
2022-04-07T22:15:23 [WARNING]: Ambiguous latency for port ‘-a Player5/audio_out 1’ (0, 640)
2022-04-07T22:15:23 [WARNING]: Ambiguous latency for port ‘-a Player5/audio_out 2’ (0, 640)
2022-04-07T22:15:23 [WARNING]: Ambiguous latency for port ‘-a Player1/audio_out 1’ (0, 656)
2022-04-07T22:15:23 [WARNING]: Ambiguous latency for port ‘-a Player1/audio_out 2’ (0, 656)
2022-04-07T22:15:23 [WARNING]: Ambiguous latency for port ‘-a Player2/audio_out 1’ (0, 656)
2022-04-07T22:15:23 [WARNING]: Ambiguous latency for port ‘-a Player2/audio_out 2’ (0, 656)
2022-04-07T22:15:23 [WARNING]: Ambiguous latency for port ‘-a Player3/audio_out 1’ (0, 656)
2022-04-07T22:15:23 [WARNING]: Ambiguous latency for port ‘-a Player3/audio_out 2’ (0, 656)
2022-04-07T22:15:23 [WARNING]: Ambiguous latency for port ‘-a Player5/audio_out 1’ (0, 656)
2022-04-07T22:15:23 [WARNING]: Ambiguous latency for port ‘-a Player5/audio_out 2’ (0, 656)
I’m not sure what the numbers in parentheses mean, but the last number continues to grow with each iteration of the jack_lsp command.
I’m too much of a newbie to know how to do this – but if you could give me a clue, I could load the older version of Jack on the machine and see if the problem goes away.
PS: regarding the capture and playback latency point you raised. Those -mm audio_in ports are each the target for 4 other Player ports – a mix-minus monitoring mix that allows a player to hear the others. The port is also the target for a send from a bus that allows me to add themselves back into their own mix (thus removing the ‘minus’ from the mix-minus for those players that want to hear themselves via Jacktrip rather than locally).
I disconnected the bus-connection to those 2 audio_in ports to test whether there was a conflict between the bus connection and the channel-strip connections…
Clue #1 - the ‘restarting session’ messages stopped
Clue # 2 - the log-warnings continue, but now their values don’t increment.
2022-04-07T22:36:56 [WARNING]: Ambiguous latency for port ‘-a Player1/audio_out 1’ (0, 32)
2022-04-07T22:36:56 [WARNING]: Ambiguous latency for port ‘-a Player1/audio_out 2’ (0, 32)
2022-04-07T22:36:56 [WARNING]: Ambiguous latency for port ‘-a Player2/audio_out 1’ (0, 32)
2022-04-07T22:36:56 [WARNING]: Ambiguous latency for port ‘-a Player2/audio_out 2’ (0, 32)
2022-04-07T22:36:56 [WARNING]: Ambiguous latency for port ‘-a Player3/audio_out 1’ (0, 32)
2022-04-07T22:36:56 [WARNING]: Ambiguous latency for port ‘-a Player3/audio_out 2’ (0, 32)
2022-04-07T22:36:56 [WARNING]: Ambiguous latency for port ‘-a Player5/audio_out 1’ (0, 32)
2022-04-07T22:36:56 [WARNING]: Ambiguous latency for port ‘-a Player5/audio_out 2’ (0, 32)
2022-04-07T22:36:56 [WARNING]: Ambiguous latency for port ‘-a Player1/audio_out 1’ (0, 32)
It’s the minimum and maximum latency (same as reported by jack_lsp -l).
For playback ports it’s
“How long will it take until the signal arrives at the speaker”.
For capture ports:
“How long has it been since the signal arrived at the input/mic (really, at the edge of the jack-graph)”.
Ideally both numbers are identical: min = max = actual latency.
The problem you’re facing is a feature of JACK. JACK allows you to connect anything to anything, regardless if the connection make sense.
We say “JACK provides mechanism, but does not enforce policy”: JACK just passes data and information around. It tells jack-apps about the latency but does not compensate (delay the signal) by itself.
In theory jack-clients can adapt, adjust their port latency (to match the max), and announce it back. This can avoid ambiguous latency situations, but in practice few jack-clients do that. In the past this lead to issue with recording in Ardour not being aligned properly, so we added a warning…
In your case it seems that jack-trip updates its latency every now and then, which can make sense, depending on the network connection and buffering, but it’s really counter-productive.
Right, I understand what the lsp_jack command is doing. I’m pointing to the fact that touching Jack with it (which I do once a second) triggers the warnings. Two things have changed between a scenario that runs reliably (Debian 11, Ardour 6.5) and one that doesn’t – Jack and Ardour.
The other point I’d make, is that these are very regular events – they happen once a second (probably due to the lsp_jack call in my script) which tends not to support a hypothesis that it’s Jacktrip changing latency. I would expect those errors to be irregular. In this case I further doubt that Jacktrip is changing latency because I’ve set the latency manually in Jack at both ends of the connection.
I’ll try to figure out how to run Jack 1.9.17 and report back.
Oh. There have been updates to latency compensation and also ambiguous latency detection in 6.7 (and again in unreleased 7.0-pre0 September’21).
Before diving deeper I suggest to test a https://nightly.ardour.org/ (demo is fine). It can be installed in parallel to distro versions. Note: test with some throwaway session, v7 sessions can no longer be loaded in v6.
I loaded the overnight on a Debian 11 server so’s to be able to test without any other changes. The results are found in another very tall file full of terminal sessions interspersed/introduced by the way that I launched Ardour7.
At the end, I uninstalled the overnight, and included the terminal session of a normal (successful/no-errors) run with Ardour6 against the same template file on the same machine. Here’s the link
