Hi,
> I learned that the callback passed in AUD_open_out, (lets call it the write
> audio callback,) is supposed to mix and write the
> buffers to HWVoiceOut. I have written that, the basic algorithm being:
>
> 1. Pop element from tx virtqueue.
> 2. Get the xfer header from the elem->out_sg (iov_to_buf(elem->out_sg, 1,
> 0, &hdr, sizeof(hdr)))
> 3. Get the buffer from elem->out_sg (iov_to_buf(elem->out_sg, 1,
> sizeof(hdr), &mixbuf, period_bytes))
> 4. AUD_write the buffer
AUD_write returns the number of bytes actually accepted.
In case the audio backend consumed the complete buffer you can go ahead
as described. Otherwise stop here and resume (try AUD_write() the
remaining data) when the callback is called again.
The callback that is supposed to write the buffers to HWVoiceOut has to
do it such that it only writes the buffers for the streams that it was called by. The tx
virtqueue is going to have buffers for all the streams. How do I handle this situation?
Say, I have 3 output streams 0, 1 and 2, the callback was called on stream 0, how do
I only play buffers corresponding to this stream? Is there a way by which I could iterate over
the virtqeueue?
If not then I should probably store the VirtQueueElements corresponding to a specific stream
in the stream itself. I have to store the elements because I'd have to write to the response and
mark these elements as used, (via virtqueue_push i think.)
Also, is virtqueue a 'queue'? I remember reading in the specs that the device can consume
the buffers in any order it prefers unless a feature bit is negotiated. So does virtqueue_pop
always return the first element that entered the queue? (FIFO?)
If it is FIFO, then I think the only way would be to iterate over the virtqueue. However if `virtqueu_pop`
does return the last inserted element, I can use `handle_tx`