Added, thanks!
https://hg.libsdl.org/SDL/rev/9bdb766ec7e5

Some minor nitpicks on this patch:

+    while (SNDIO_sio_read(this->hidden->dev, buf, sizeof(buf)) != 0) {
+        /* do nothing */;
+    }

Can this return -1 if there's an error? If so, this will loop forever if a USB audio device is unplugged or whatever, so we should loop while sio_read() > 0.

+        SNDIO_sio_open(devname != NULL ? SIO_DEVANY : devname,

That probably was meant to be "devname == NULL", right?

Also, CaptureFromDevice() needs to block enough to return a value > 0, but it doesn't have to return a full buffer; the calling code knows to loop again to get more data, but it considers a zero return value as a fatal error. I don't know if that simplifies the code much to only block until _something_ is available instead of _enough_ is available, but that option is available to you if it makes things cleaner.

--ryan.

> Can this return -1 if there's an error? If so, this will loop forever if a USB audio
> device is unplugged or whatever, so we should loop while sio_read() > 0.

`sio_read' returns an unsigned value with zero indicating an error.

> That probably was meant to be "devname == NULL", right?

Right, sorry.

Created attachment 2803 [details]
Fixes for the sndio backend

(In reply to kdrakehp from comment #4)
> Created attachment 2803 [details]
> Fixes for the sndio backend

(this wasn't the patch, can't you attach again? Sorry.)

--ryan.

> `sio_read' returns an unsigned value with zero indicating an error.

Oh, ok, cool.  :)

--ryan.

Created attachment 2804 [details]
Fixes for the sndio backend

(In reply to Ryan C. Gordon from comment #5)
> (In reply to kdrakehp from comment #4)
> > Created attachment 2803 [details]
> > Fixes for the sndio backend
> 
> (this wasn't the patch, can't you attach again? Sorry.)
> 
> --ryan.

That is odd.  I have added the patch again.

> That is odd.  I have added the patch again.

Thanks!

This patch is now https://hg.libsdl.org/SDL/rev/dfa9358ae3e0 ...

One last question (just to make sure)...in SNDIO_CaptureFromDevice, this doesn't block at all; this happens in a background thread in SDL, but I assume this is burning the CPU core at full speed waiting for more data to arrive; should we put a sleep in there? (and/or can the device's file descriptor just be set to block, so reads don't return until there is data or an error?).

--ryan.

> One last question (just to make sure)...in SNDIO_CaptureFromDevice, this
> doesn't block at all; this happens in a background thread in SDL, but I
> assume this is burning the CPU core at full speed waiting for more data to
> arrive; should we put a sleep in there? (and/or can the device's file
> descriptor just be set to block, so reads don't return until there is data
> or an error?).
> 
> --ryan.

No, poll(2) waits for an event on the file-descriptor list set by
`sio_pollfd'.  The way I used it in the `CaptureFromDevice' function
waits for the `POLLIN' event to signal that there is data available
to read.  It should only ever execute the loop body once, unless an
interrupt is received.

The `FlushCapture' function is what requires the device to be
non-blocking, because sndio itself does not provide a way to flush
the buffer.

Now that I think about it, I forgot something else.  The comparison
for poll should be ``< 0'' not ``<= 0'', an interrupt would cause
the `CaptureFromDevice' function to incorrectly return zero.

Sorry about that.

Created attachment 2806 [details]
Fix the incorrect check on poll(2)

> No, poll(2) waits for an event on the file-descriptor list set by

Oh, sorry, you're right. I saw "poll" and ignored the INFTIM argument.

Your poll() fix is now https://hg.libsdl.org/SDL/rev/41d93b7fd207, thanks!

I think this resolves everything, so I'm marking this bug resolved again. Thanks again for working through this with me.  :)

--ryan.