Lowering usleep time and checking if ci.ptr is zero made all the glitches in the sound go away. I do need to run it for quite a few times to validate that, but in the worst case I significantly lowered the probability of gibberish on the output. Next, I need to calculate the usleep time based on ci.ptr.

The usleep based mmap example based on official OSS example. There are three big things about it right now that make it not-so-perfect:

I think I'll try my luck with http://manuals.opensound.com/developer/mmap_test.c.html first and fit it into our example and once the usleep version works, see what are the values of ptr compared to the ones in kqueue scenario. My thinking is "if I can't fix it, move to simpler example", which I'm hoping the official docs are. Anyway, I didn't give up on this code, I just need to approach it from the different angle, for now.

Give more info on failed set attempt

Fix copy/paste typo.

Check sample format, rate and channels after they are set.

Check sample rate and format after ioctl call. While here, print sample size and number of channels of configured device.

I am looking into the code in general and I want to figure out how to display information so it makes more sense, not just dump printf.

Rebase after oss.h fix

Remove needless include

Map or allocate buffer in oss_init. For some reason with this patch probability of producing proper sound is way higher. I still have to add GETIPTR/GETOPTR checks and usleep based on the position.

Let me try to compensate the drift by reading SNDCTL_DSP_GETIPTR and SNDCTL_DSP_GETOPTR and experiment with that for a bit.

I forgot to edit Makefile. Fixed now.

Remove extra functions as they are very simple

That's the strange thing. If I run it 20-30 times, I would get roughly half of the times distorted sound, half of the times normal sound. Also, I tried having one config and two events for read and write, but I couldn't produce any sound like that. Anyway, let me fix this example to conform to the comments and lets go from there.

I tested simple, select and poll on the real hardware. As that machine is not running CURRENT, I can't test kqueue. @christos, do you have any means on testing it on real hardware? I tried to test it in bhyve with -s 6,hda,play=/dev/dsp,rec=/dev/dsp but none of the examples work properly that way.

Reword comments and fix Makefile

I already fixed those as well as share/examples/Makefile, I just want to check if everything is working, and that has to wait for my day job to finish.

I just realized I copy/pasted the same first license comment everywhere. Can you tell me what should I put in the "Copyright" lines, please?

Improve comment regarding usage of interleaved format and channels.

I tested all examples with real hardware. Well, all except kqueue, as the machine with the actual hardware is 14.3 based.

Fix to_channels and to_interleaved and address other comments.

Move contents of README into comments, mostly in oss.h

More cleanup from old example

I just remembered one more comment I can't find. It is about setting fragments. I'd like to leave it there and in the comments mention that setting fragments is optional. I'd like to have a full examples so people interested in sound don't have to wonder how things are done. To be honest, official OSS documentation could use some improvement. At least I found it hard to understand what exactly I need to do.

I hope I found all comments. It was not obvious I would have to click on a line number beside comment to get old comments.

I missed old comments as I moved files from oss directory. It took me a while to realize how to read them. Sorry for the noise.

I really hope this is OK way to handle 24 bits.

The directory where these files live is "oss". As everything is about OSS in "sound" directory, should I perhaps rename oss to audio? My reasoning is that there are audio and MIDI examples that we can show, so "oss" is a bit missleading. Or maybe have share/examples/oss and audio and midi under it? Anyway, when I started writing the examples I only wrote audio part, so "sound" was appropriate, which probably isn't the case any more.

Use per-config buffer.

Address the rest of the comments (without moving README to comments).

I hope I addressed all the comments except showing example for both polling directions and readme. I think if a person understands polling in one direction, it is easy to extrapolate how to work with two directions. As these are examples, not complete guides, I would argue that this is good enough, especially in kqueue case where both directions would create two events and example would become more complicated. As I do plan to add mmap example once this is merged, that example will have input device and output device so even that configuration will be shown, I just don't think that all examples should split the sound card into two directions. As for the readme, good catch, I didn't think of that, but let's make the code in the examples good and I'll change the readme to correspond to those changes.

Add triggering.

One more wrong device fixed

Use default DSP device

New sentences on new lines

So, if I understand right, I should move oss_init into the test file and simplify it. What does it mean "simplify"? I guess mmap parts can be removed, but what else do you want gone? The thing is that I don't know what is the minimum that we can work with. Maybe just set sample format and remove all the rest? Also, what should I do with oss.h then? I mean, everything in that file is made just so the oss_init would work.

In D53029#1215698, @christos wrote:

I've been testing the patch and trying to fix the panic you mentioned in D53029, although there is one more panic in dsp_kqdetach() that I'm working on. The code needs a few changes, is it okay if I take over the revision, at least for now, so that it's easier to upload the new changes?

Running polling:poll_select for the first time in VM exposes LOR while polling:poll_kqueue panics the kernel. The reason I added oss.h is to be able to use those common functions and structures in mmap based test that I have yet to write.

Fixed typos

Most notable change is removal of example, I'll add it in a new revision.

I was wrong about what SNDCTL_DSP_GETOSPACE and SNDCTL_DSP_GETISPACE do, hence the update.

While at it, I decided to add all polling/events into one example.

I changed the code based on the comments, but I didn't add test program, yet. Give me some more time.

In D46307#1057113, @dev_submerge.ch wrote:

I suppose the original idea by @meka_tilda.center was to implement another example using mmap, at least there's code fragments for that. What's the plan regarding a mmap example?

I had to remove dev/sound/unit.c optional sound from sys/conf/files but otherwise it works.

Works here, too. I did only the short test, but no EBUSY.

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?

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).

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

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

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

An example

Ah, so, single argument with quotes. If broken into multiple lines with "\" it makes fwget's output weird, hence one huge line.

It would be better if addpkg supported multiple arguments, but with current implementation we have to use multiple invocations.

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.

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#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.

If you're going to change format, why not use tree, as it feels natural for sysctl. One existing example would be dev.pcm.<number> so following that, we could have security.mac.ipacl.<jid>.<rule> and .family and .address (or maybe .range) as leafs. It is not set in stone that it has to be like that, but given it's sysctl, it feels more natural to me, so please give it a thought. Also, as it is about jail, it would also feel more natural to have this tunables under security.jail.<jid>

This patch fails to apply to CURRENT. I am using dhcpcd-10 since it was released (and used previous versions) for DHCP, SLAAC and DHCPv6, all on the same network. That's the closest to testing I can get in current state. If this patch is updated I would love to test it. Of course, if updating patch is required, I would love to do it, but at this point I'm not sure I know how.

Is there something we can do to make dhcpcd part of 14.0-RELEASE besides testing this patch?