io plugin: polling on unix socket, socket buffer sizes ?

[Stefan Schoenleitner <dev.c0debabe@gmail.com>]

Hi,

I'm currently writing an alsa io plugin that should exchange PCM samples
with another piece of software over a unix socket.
More precisely exactly 160 PCM samples with 16bit each should be
exchanged at a time.

AFAIK the alsa plugin framework works by utilizing poll().
Thus if the plugin is used for playback it would use POLLOUT on the
socket to see if the next chunk of data can be written to the socket
without blocking.

By reading quite a lot of alsa code (including pcm_bluetooth.c from
bluez) it seems that I need to set the socket buffer size to a value
small enough, right ?

Thus if I would like to send one period consisting of 160 samples (with
16bits each) at a time, I would need to set the unix send buffer size to
320 bytes.

This way some kind of handshaking between my application and the alsa
plugin would be established:
Each time the application reads a full period of data from the socket,
the alsa plugin will start to send the next period as poll() will return
the POLLOUT event.
(Thus the transfer callback function would be called in the plugin code.)

Is this correct so far ?


To test the behavior I wrote two small code snippets:

One is unix socket reader that reads a chunk of 10 bytes at a time and
then sleeps for 10 seconds.
The socket recv buffer size SO_RCVBUF has been set to 10 bytes with
setsockopt().

The other snippet is the unix socket writer:
It sets the socket send buffer size SO_SNDBUF to 10 bytes so that after
writing 10 bytes to the socket, poll with POLLOUT would block until the
other end (the reader) reads some bytes and the send buffer is drained.
The reader polls on the socket with a timeout of 1 sec and in case poll
returns the POLLOUT event, it writes a chunk of 10 bytes to the socket.


With these small code snippets I would expect the following behavior: