Implement VirtIO sound device capture

[Cuda-Chen]

Summary by cubic

Implements VirtIO sound capture (RX) with PortAudio input, RX virtqueue handling, and circular buffering so input audio can be delivered to the guest. Also exposes separate input/output streams with accurate device info.

• New Features
  • Added RX virtqueue handlers (normal/flush) with default flush stream_id = 1.
  • Opened PortAudio input stream and RX callback to capture frames and enqueue to the driver.
  • Implemented circular intermediate buffer (buf_sz, buf_idx) and RX enqueue/dequeue helpers.
  • Exposed two streams (output + input), mono S16, with per-stream jack/pcm/chmap info.
  • Added RX worker thread, mutex/cond vars, and VSND_QUEUE_RX notifications.
  • Applied direction-aware flush in pcm_release and set RX response length/status.
  • Added CI sound tests for playback and capture and wired them into GitHub Actions.

^{Written for commit fd4f538. Summary will update automatically on new commits.}

[jserv]

Rebase to avoid unnecessary merge commits.

[jserv]

__virtio_snd_rx_frame_enqueue() never increments buf_ev_notity or signals the condition variable, but __virtio_snd_rx_frame_dequeue() waits on it:

  // In __virtio_snd_rx_frame_dequeue:
  while (props->lock.buf_ev_notity < 1)
      pthread_cond_wait(&props->lock.readable, ...);  // BLOCKS FOREVER

The TX path correctly does:

  props->lock.buf_ev_notity++;
  pthread_cond_signal(&props->lock.readable);

Fix: Add after list_push() in __virtio_snd_rx_frame_enqueue:

  props->lock.buf_ev_notity++;
  pthread_cond_signal(&props->lock.readable);

[Cuda-Chen]

The buf_ev_notity will be increased and then signals the update of CV after consuming all the virtq elements when calling virtio_snd_rx_desc_normal_handler():

// In VSND_GEN_RX_QUEUE_HANDLER macro

virtio_snd_prop_t *props = &vsnd_props[stream_id];                   
props->lock.buf_ev_notity--;                                         
pthread_cond_signal(&props->lock.writable);

The virtio_snd_tx_desc_normal_handler() also has the same design.

The reason is that the driver should populate a period size of PCM frames (except the end of stream) as mentioned by VirtIO standard:

5.14.6.8.2.2 Driver Requirements: Input Stream

• The driver SHOULD populate the rx queue with period_bytes sized empty buffers before starting the stream.
• The driver MUST NOT place device-readable buffers into the rx queue.

[jserv]

__virtio_snd_rx_frame_dequeue() does list_del(&node->q) but never free(node):

  if (node->pos >= node->len)
      list_del(&node->q);  // Missing: free(node);

[jserv]

The RX circular buffer design stores node->addr = props->intermediate + idx, meaning multiple nodes can point to overlapping regions. When the buffer wraps, older data gets overwritten while nodes still reference it.

If enqueue outruns dequeue, later writes corrupt earlier node data. The TX path copies data differently (uses the queue nodes as independent buffers).

[Cuda-Chen]

Hi @jserv ,

Thanks for the suggestion.
Though it will take some time, I think let's stick the list of frames rather than the circular buffer design.

[jserv]

Though it will take some time, I think let's stick the list of frames rather than the circular buffer design.

You should express with strong reasons.

[Cuda-Chen]

Hi @jserv ,

The circular buffer design requires no further memory allocation, whereas the list of frames design requires one memory allocation every time the device stores the content of a frame.

[jserv]

Debug Printf Pollution
Multiple fprintf(stderr, ...) debug statements throughout the RX path should be removed before merge.

[jserv]

Can we perform loopback tests with virtio sound device?

[Cuda-Chen]

Can we perform loopback tests with virtio sound device?

You mean aloop or a device loopback testing command like arecord -C | aplay -?

[jserv]

You mean aloop of a device loopback testing command like arecord -C | aplay -?

The headless verification is crucial for CI/CD integration.