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.

I finally found the time to test this patch. I'm running CURRENT and I only have Behringer XR18 at my disposal. First test I ran was lowering the buffer_ms to 1 and just playing audio for few hours. I didn't tweak virtual_oss parameters or anything, and audacious was using virtual_oss. Not a single jitter, glitch or xrun in those few hours, no audible defects of any kind. In the following days I intend to test the latency with jack_iodelay.

This change looks very useful, thanks for figuring this out!

Ping! Also, patch briefly tested on 15.0-CURRENT as of today. No regressions, works as expected.

@mav I hope it's ok to add you as a reviewer / committer here? Or should I ask someone else instead?

FYI, my patch is here D41942: snd_uaudio(4): Adapt buffer length to buffer_ms tunable. for review. I'll add more info this weekend.

I don't know how to do this correct in one patch: 1) rename port, 2) update to new version.

In D41048#955081, @arrowd wrote:

There is something strange going on with this diff. When trying to apply it via arc patch D41048 I do get the audio/mumble-server port, but it contains PORTNAME=murmur and PORTVERSION=1.3.3. Maybe this is because the patch doesn't apply.

@vvd can you please refresh it?

I don't know how to do this correct in one patch: 1) rename port, 2) update to new version.
So patch can look weird and possible not all tools can work correctly with it. This part:

There is something strange going on with this diff. When trying to apply it via arc patch D41048 I do get the audio/mumble-server port, but it contains PORTNAME=murmur and PORTVERSION=1.3.3. Maybe this is because the patch doesn't apply.

ping :-(

In D41627#953185, @dev_submerge.ch wrote:

The patch I'm working on also does the latter. With a reduced buffer size, I'm confident that we can have less latency at a 4ms interval than currently at 2ms. I think that would make 4ms an acceptable default for everybody.

Update: Looks like the current snd_uaudio implementation actually does transfers according to USB standard, it spreads the isochronous frames over the whole transfer interval. I was misled by parts of the code, and the fact that usbdump(8) only shows the first millisecond of longer transfers. Sorry for the noise.

I didn't promise it to be easy, but I think USB transfer size should be as close to sound(4) fragment size, if it can't be equal, as for other sound cards.

I didn't promise it to be easy, but I think USB transfer size should be as close to sound(4) fragment size, if it can't be equal, as for other sound cards.

Well, these are three different topics then:

As I can see, uaudio_buffer_ms is primarily used to set intr_frames variable. I haven't dug deep, but looks like it controls the size of individual USB transfer, which I suppose affects USB controller interrupt rate, or at very least the rate of its DMA transfers. Frequent DMA transfers may prevent deep sleeps on CPU package-level. Frequent interrupts in addition wake up at least one CPU core. It all burns a lot of power, that may be critical for laptops and embedded systems, while not every application require so low latency. I generally don't like tunables, and I would be happy to remove this one, but I don't like the idea of getting 1KHz of USB interrupts for every sound application. Sound subsystem already has its own concept of buffer sizes and latency control. Can't those values be reused here without additional knobs to only have level of overhead required by specific application?

After some thought I have a different proposal:

ping

Chiming in here as I have some experience with the snd_uaudio module and its code. I do support this change, but I think the title is a bit misleading.

In D41627#949637, @mav wrote:

I am sorry, but once again: in this patch you change allowed minimum, but do not change the default on line 99, right?

I guess heat got to my head :) Thank you, good catch! Update is coming.

In D41627#949513, @meka_tilda.center wrote:

In D41627#949189, @mav wrote:

After your initial commit Hans reduced the default value from 8ms to the minimum of 2ms. I wonder if it is still OK or you'd like to reduce default also.

If you look at the commit linked in description you'll see that that's the commit that made it possible to go to 2ms. Hans asked me what works for me and back then 2ms really worked well. That being said, I'm literally fixing my error from few years ago.

In D41627#949189, @mav wrote:

After your initial commit Hans reduced the default value from 8ms to the minimum of 2ms. I wonder if it is still OK or you'd like to reduce default also.

As a disclaimer, I know very little to nothing about USB.

After your initial commit Hans reduced the default value from 8ms to the minimum of 2ms. I wonder if it is still OK or you'd like to reduce default also.

This looks good to me.

Replaced shebang with statically patch.

Thanks!

I committed R11:3b2ff2ef194c and R11:f0f843322841 (plus a quick typo fix R11:5f6b3eda2234) to address this issue. You can now set:

DEFAULT_VERSIONS+= ebur128=legacy

in make.conf to use the C implementation tree-wide.

In D41048#943752, @eduardo wrote:

The problem with UPDATING is that it's only visible to people with a checked-out ports tree; people who only use binary packages will never see the messages.

pkg-updating(8) - display UPDATING entries of software packages

In D41048#934479, @adamw wrote:

The problem with UPDATING is that it's only visible to people with a checked-out ports tree; people who only use binary packages will never see the messages.

You still want to put stuff in UPDATING, but pkg-message is actually the most helpful as it's visible to everyone using pkg (FreeBSD upstream, poudriere, etc.).

See https://docs.freebsd.org/en/books/porters-handbook/pkg-files/#porting-message, especially "Example 4: Display a Message on Upgrade."

Added pkg-message.

After discussion in IRC I updated the patch:

• Keep old names for user and group is "technical debt" and "confuse the users" (especially new).
• Use new UID and GID is difficult to migrate for running systems - find and change owner for all files required for port.

So, IMHO, rename user and group is "the lesser of the evils".

In D41473#944573, @arrowd wrote:

PLUS implies EBUR* and EBUR* implies PLUS? This looks wrong.

All correct:

• EBUR used for PLUS only, so if turn on EBUR, then automatic turn on PLUS;
• PLUS require EBUR.

This is the "logic".

PLUS implies EBUR* and EBUR* implies PLUS? This looks wrong.