On Wed, Feb 25, 2015 at 03:08:01AM +0000, Sam Good wrote: > >From sndio design, it looks like non-blocking (like in sio_write) can be > >done with poll. > sio_pollfd can be used to obtain the pollfd struct which contains the file > descriptor fd. > The fd descriptor seems to be equivalent to the unix stream for the sound > playing device. > > Would it be possible to use the file descriptor fd with kqueue > instead of poll?
Not directly. It's a "private" file descriptor. The client code transmits meta-data (flow control information) that's hidden from the caller. For instance, the server may send timing information consumed internally by the library; we don't expose it with sio_read(). In this case, we don't want the POLLIN event to be set, as there are no samples to read. This is why the library exposes sio_pollfd() and sio_revents() instead of exposing the bare file descriptor(s). Typically sio_revents() consumes the meta-data and adjusts the POLLIN and POLLOUT flags. > (I wanted to adapt an application that uses kqueue for > internet/TCP server listening, and be able to add an audio > playing capability; I wanted to try to use kqueue for both. I > also wanted to learn more about using kqueue) > > I wrote a basic program that gets the sndio playing device file > descriptor fd from sio_pollfd, and then adds that fd to the > kevent with filter EVFILT_WRITE. Then loop with kevent appears to > return that the fd is ready for WRITE, and the kevent return data > shows '4096' (available space in buffer for write) but sio_write > returns with value 0, indicating that no bytes could be written > into the output buffer. If this is the socket fd, this is OK, as sio_write() and the sndio interface to poll(2) does flow control. They may be buffer space available locally, but the device may not be ready to accept it. > Is there something different about the file descriptor for the > sndio output device, that kqueue/kevent can't be used? > There's no interface to kqueue in the sndio api yet (i mean, there's no equivalent of sio_pollfd, sio_revents, etc) because we never needed it, probably because as programs use few descriptors, poll(2) did the job so far. Furthermore, as kqueue was never used for audio, I'm not sure that the corresponding audio(4) code was tested.
