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: