Sorry about that. I was on a branch off of main, but it was a bit stale.

• Rebase against latest main.
• Make more use of defined variable.

This is not diff'd against main. Also please address the other inline comment.

Switched to using bool for the type instead of uint8_t.

Hopefully, fixed.

• Remove unneeded != 0 expression.
• Use proper full context diff. Do *not* let --no-prefix anywhere near the diff. :)

In D55605#1274023, @scf wrote:

In D55605#1273962, @christos wrote:

Something is messed up with the file paths here. (dev/sound instead of sys/dev/sound).

I am not sure what happened. The diff starts with:

diff --git sys/dev/sound/pcm/feeder_volume.c sys/dev/sound/pcm/feeder_volume.c
index fc4ed1bbb0a5..c1a33dcdd8a3 100644
--- sys/dev/sound/pcm/feeder_volume.c
+++ sys/dev/sound/pcm/feeder_volume.c
@@ -1,350 +1,360 @@
 /*-
  * SPDX-License-Identifier: BSD-2-Clause

I have not used git-arc, but it looks like I need to try it.

In D55605#1273962, @christos wrote:

Something is messed up with the file paths here. (dev/sound instead of sys/dev/sound).

Something is messed up with the file paths here. (dev/sound instead of sys/dev/sound).

Updated diff with full context.

Can you please generate the diff with full context or upload it with git-arc?

Oops, fix typo

In D45071#1029790, @vvd wrote:

libabsl*.so:devel/abseil from libprotobuf-lite.so:devel/protobuf from option CHROMECAST.

CHROMECAST_LIB_DEPENDS+=libabsl_base.so:devel/abseil

libsrt.so:www/srt and libaribb24.so:multimedia/aribb24: --disable-srt --disable-aribsub --disable-aribb25.
libabsl*.so:devel/abseil from libprotobuf-lite.so:devel/protobuf from option CHROMECAST.

Or we can patch modules/access/rdp.c:

diff -ur multimedia/vlc/files/patch-modules_access_rdp.c.orig multimedia/vlc/files/patch-modules_access_rdp.c
--- multimedia/vlc/files/patch-modules_access_rdp.c.orig
+++ multimedia/vlc/files/patch-modules_access_rdp.c
@@ -1,4 +1,4 @@
---- modules/access/rdp.c.orig  2016-07-22 12:10:45 UTC
+--- modules/access/rdp.c.orig  2023-02-11 09:33:17 UTC
 +++ modules/access/rdp.c
 @@ -45,18 +45,6 @@
  # include <freerdp/version.h>
@@ -19,7 +19,13 @@
  #include <errno.h>
  #ifdef HAVE_POLL
  # include <poll.h>
-@@ -140,6 +128,7 @@ static void desktopResizeHandler( rdpCon
+@@ -139,11 +127,12 @@ typedef struct vlcrdp_context_t vlcrdp_context_t;
+
+ /* updates handlers */
+
+-static void desktopResizeHandler( rdpContext *p_context )
++static int desktopResizeHandler( rdpContext *p_context )
+ {
      vlcrdp_context_t * p_vlccontext = (vlcrdp_context_t *) p_context;
      demux_sys_t *p_sys = p_vlccontext->p_demux->p_sys;
      rdpGdi *p_gdi = p_context->gdi;
@@ -27,7 +33,7 @@

Upstream committed our patches to 3.5.1 branch - replaced audio/audacity/files/patch-* with patch from this commit.

Removed unused LIB_DEPENDS:

Warning: you might not need LIB_DEPENDS on libasound.so
Warning: you might not need LIB_DEPENDS on libcurl.so
Warning: you might not need LIB_DEPENDS on libopenjp2.so
Warning: you might not need LIB_DEPENDS on libpng.so
Warning: you might not need LIB_DEPENDS on libturbojpeg.so

And pet portclippy.

The change looks fine but remember that maintainer timeouts don't work on Phab. You need to create a bugzilla PR for this.

D43545 takes care of this change. Should we close this?

In D41942#995265, @meka_tilda.center wrote:

Interesting. I just tested, and if I boot my machine while interface is on, kld_list and buffer_ms together do the trick. I mean, jack_iodelay reports exactly same latency as if I loaded the module, set buffer_ms and then turned on the interface. Maybe my interface is slow to respond initially, so sysctl has time to kick in?

In D41942#995271, @christos wrote:

In D41942#995078, @dev_submerge.ch wrote:

@christos: Thanks! Since @mav didn't participate here, would someone else be so kind to commit this? Unless there's other issues that weren't brought up yet.

I will commit it.

@meka_tilda.center Sorry about the extra work, I somehow thought you would know that. The handling of buffer_ms didn't change in this regard. My approach was to communicate it simply as a /boot/loader.conf tunable. IMHO that's more digestible by end users, less error prone. Tell them to (re-)attach the device only after buffer_ms is set would probably also work. But kld_list+=snd_uaudio and /etc/sysctl.conf come too late, due to snd_uaudio being automatically loaded early in the boot process. You'd have to explicitly kldunload snd_uaudio at that point to make the devices reattach.

I agree with @meka_tilda.center on this. We should have a man page entry for this as it's not really obvious.

In D41942#995078, @dev_submerge.ch wrote:

@christos: Thanks! Since @mav didn't participate here, would someone else be so kind to commit this? Unless there's other issues that weren't brought up yet.

Interesting. I just tested, and if I boot my machine while interface is on, kld_list and buffer_ms together do the trick. I mean, jack_iodelay reports exactly same latency as if I loaded the module, set buffer_ms and then turned on the interface. Maybe my interface is slow to respond initially, so sysctl has time to kick in? Anyway, if I were to do it differently, what should I do? Load module and set buffer_ms in loader.conf?

@christos: Thanks! Since @mav didn't participate here, would someone else be so kind to commit this? Unless there's other issues that weren't brought up yet.

That's a great improvement. LGTM.

A misunderstanding. I though you wanted me to make sure there are no reconnects. Anyway, loading the driver first, then setting buffer_ms and then turning on the interface yields the following results

period = 192
buffer_ms = 1
  690.921 frames     14.394 ms total roundtrip latency
	extra loopback latency: 306 frames
	use 153 for the backend arguments -I and -O

Now this is a great improvement! Can we document it somewhere? Suggesting, for example, to put kld_list+=snd_uaudio and then set buffer_ms as any other sysctl? In my oppinion, if we spent so much time figuring out how to properly do the measurement, I'm sure other people will need help with their setup, too, so why not make it easier for them and put this into snd_uaudio(4).

In D41942#994910, @meka_tilda.center wrote:

I didn't answer about re-plugging. No, the interface is always connected and I don't touch the cables.

I didn't answer about re-plugging. No, the interface is always connected and I don't touch the cables.

I see what you mean. I tested with buffer_ms of 1 and 8 and I get almost exact numbers:

period = 192

Meka, according to USB descriptor your audio interface is fine with 1ms intervals (bInterval = 0x0004). So that's not the problem. And the latency doesn't even change without this patch, we know that worked before. Did you replug the device after you changed the buffer_ms sysctl? New buffer_ms values may not become effective immediately, depending on your settings.

If you want to test it - get current patch.
If you want to see diff with old murmur - check history patch here: https://reviews.freebsd.org/D41048?id=133095

Trying to update diff using arcanist.