To be fair, I don't think these changes are meaningful. mixer(8) will fail for all the cases you are trying to catch anyway, and I think the messages are clear enough already.

Should we commit this?

Continued here: https://ron-dev.freebsd.org/FreeBSD/src/pulls/63

I don't have a device like that right now. But everything works as expected? Playback, recording, latencies, etc?

Tested with my HW, no problems. Is there some particular way you are testing this?

This looks good. The only thing I am still skeptical about are the various casts you've introduced, not sure if they are needed. I will be testing the patch as well.

In D57833#1328671, @meka_tilda.center wrote:

Before I do that, let's get the code in perfect shape. I mean, should I change chn_polltrigger and chn_pollreset to handle mmap or should I leave it as it is now?

In D57833#1327561, @meka_tilda.center wrote:

It's not about mmap, it's about kqueue. Look at the following code:

if (bs->prev_total < c->lw)
    delta = c->lw;
else
    delta = bs->total - bs->prev_total;

For this to report discrete events, prev_total must be reset to total after each firing. The select/poll path does exactly that inside chn_poll():

if (chn_polltrigger(c)) {
    chn_pollreset(c);
    ...
}

Kqueue cannot safely use that same per-channel reset for two reasons:

1. Activation/delivery race. If you reset prev_total inside dsp_kqevent() when KNOTE_LOCKED activates the knote, the event has not yet been delivered to userland. The next interrupt runs kn_scan() again, sees total - prev_total < lw, and drops the event.
2. Multiple knotes on one channel share prev_total. If two kevent registrations are watching the same channel, resetting prev_total for one knote prevents the other from ever seeing its own low-watermark edge.

So chn_polltrigger()'s mmap logic is correct, but it needs a per-caller counter. Select/poll uses the single per-channel prev_total because each poll call is a fresh, one-shot evaluation. Kqueue needs a separate counter per knote, which is kn_sdata.

chn_polltrigger() has a case for CHN_F_MMAP, isn't it enough? And if not, why?

Bump.

LGTM, only some small nits.

LGTM, minus some details which I will take care of when I'll commit it. Thanks :)

The man page needs a date bump.