I rebased this patch, but the problem is that I don't have the hardware to test it. I'll try to find cheap PCIe card to test this patch.

In D54360#1244383, @christos wrote:

The USB stack seems to have a default kqfilter method,so I suppose this is why it works. Does it work properly though?

In D54360#1244366, @christos wrote:

I did not try it yet, but there is no way that the code in D54359 is related to this working, because it does not run with USB MIDI. Does it work without D54359?

Oh, it works on 15.0-RELEASE, so no wonder I wrote this patch so easily: it doesn't do anything 😄

In D54360#1244361, @christos wrote:

Does this actually work? snd_uaudio(4) does not seem to implement a kqfilter method. I haven't checked whether the USB stack has a default handler. Also see my comment in D54359.

In D54359#1244357, @christos wrote:

Also I suppose you know this code does not work for USB MIDI, at the moment. I will eventually make USB MIDI attach to it, but currently this only works for physical MIDI.

In D54359#1244356, @christos wrote:

There are a lot of MIDI patches in review that simplify the code, so this won't apply. I can rewrite it on top of them if you want.

As midi_destroy will be removed, adapt this patch for that.

Use lock instead of qlock which will be removed in the future.

The official example at http://manuals.opensound.com/developer/mmap_test.c.html uses 50ms but that proved to be too much, probably because oss_init() sets low sized buffer. I'm not sure how to derive the number of microseconds to sleep, I just used the value that worked for me. I even tried experimenting with different values, but I have no idea how to get to a value that is based on some facts or measurement.

Reverting to a version which just waits for 0.4ms between iterations. I ran this program for ~100 times on my desktop and it didn't produce any glitches. Should I remove verbose or leave it as it is?

Calculate the amount of microseconds to sleep, but keep it in the range between 400 and 800 microseconds. Position is not updated continuously, but at some frequency. That means that value we get from ioctl can not be trusted to be accurate, which is the reason to limit the maximum duration of the sleep. The minimal duration of sleep is put in place so the code doesn't call ioctl too often.

Check if input and output config are the same by checking number of bytes and number of input/output channels. I had cases where input and output channel numbers are different, as well as difference in buffer_info.bytes when the number of input and output channels is the same. I'm afraid that handling all possible cases would make this example complicated, so I chose to write the code that insists that input and output configs are the same.

Warn only if sample format/rate/channels were not set to desired values, but fail only in simple.c if the format is not the requested one.

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.