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.

Thanks for all the measurements, Meka! It seems like the buffer_ms sysctl doesn't have any effect at all. I suspect your audio interface to demand a longer interval in its USB descriptor. Could you

I missed 4ms request from you, so here are those measurements

Main branch
-----------
hw.usb.uaudio.buffer_ms = 4
period = 768
  3337.952 frames     69.541 ms total roundtrip latency
	extra loopback latency: 1033 frames
	use 516 for the backend arguments -I and -O

Thank you for the explanation. I took the measurement and I tried to get the lowest latency without jitters, so here is the complete measurement.

Main branch
-----------
hw.usb.uaudio.buffer_ms = 2

Patch against current audio/murmur.

Hi Meka, sorry to hear, hope you are well now.
Your measurements seem to be accurate. Unfortunately they do not match my expectations, as I would have estimated more like a ~12ms reduction in this scenario.
I'll try to verify my own tests, but could you measure the new default of buffer_ms=4 in your setup? And a period of 768 in addition to 512 and 1024? Thanks!
I may have to check with the version of Jack in ports, I did my measurements with the new sosso backend which does mmap io.

Sorry for the delay, I got sick (again). Anyway, it took me a while to figure out what's going on. As I didn't have speakers on, I didn't notice there are jitters, that's why the numbers don't match. I took similar measurements with higher period size in jack and these are the results

Main branch
-----------
hw.usb.uaudio.buffer_ms = 2

Clarified buffer_ms sysctl description as suggested by @emaste.

@meka_tilda.center Any comment on your test results?

Introduced UAUDIO_BUFFER_MS_MIN and UAUDIO_BUFFER_MS_MAX as constants.
Intentionally left the comments that mention 8 ms max buffer length. It
gives some understandable context and that value will probably never change
as long as current USB audio standards are supported.

I check - update from 1.3.3 to 1.3.4 is trivial. Can I update it and take maintainership without review?
Also it need LIB_DEPENDS=devel/abseil - tested in poudriere.

Added UIDs, GIDs and UPDATING.

In D41048#990567, @arrowd wrote:

In D41048#990566, @vvd wrote:

As an option, create a new port with new UID/GID, and specify DEPRECATED in the old one and for some time there will be 2 ports at the same time. And then delete the old one with an entry in UPDATINGS describing the migration process.

I actually like this plan, even without deprecating. Just leave it as it is, use new UID/GID and free old UID/GID. In the pkg-message change step 5 from pw usermod to chown -R.

In D41048#990566, @vvd wrote:

As an option, create a new port with new UID/GID, and specify DEPRECATED in the old one and for some time there will be 2 ports at the same time. And then delete the old one with an entry in UPDATINGS describing the migration process.

As an option, create a new port with new UID/GID, and specify DEPRECATED in the old one and for some time there will be 2 ports at the same time. And then delete the old one with an entry in UPDATINGS describing the migration process.

I don't know if this is what you asked for...

Patch from git format-patch -1.
Not so obvious - diff look like "rm file && create file"…

Thanks for testing, Meka! Could you elaborate on how you did the latency measurements?
Because jack_iodelay reports a decrease of only ~2ms in total roundtrip latency, whereas the extra loopback latency decreases by ~300 frames (~6ms at 48kHz). Any other changes in the setup or Jack settings?

I ran jack_iodelay with same buffer_ms value and these are the results:

Florian's patch is superior to this one, hence closing.