Re: [cdi-devel] [PATCH] CDI.audio

[Max Reitz <max@xxxxxxxxxx>]

Kevin Wolf wrote:
> True. But then Kanal is just as wrong.
That's why I used "Channel" in German when referring to channels. *g*

>>>> +struct cdi_audio_driver {
>>>> +    int (*transfer_data)(struct cdi_audio_stream* stream, size_t buffer,
>>>> +        void* memory);
>>>
>>> Would it make sense to use a cdi_mem_area instead of size_t/void*?
>>
>> May be true, though I don't think it's a big difference whether the driver receives the structure or just the vaddr, because I don't think any driver will use this buffer directly without copying its content.
> 
> Well, you never know. And even if it converts it to a linear buffer this
> might mean that we can save an additional copy in the OS.
OK.

>>> How is success/error defined? You say "The amount of data transmitted
>>> equals the buffer's size" (I assume this refers to stream->buffer_size).
>>> So is buffer != stream->buffer_size an error or would it result in
>>> something like a short write?
>>
>> I guess it would be considered an error (though I don't know why it should partially fail).
> 
> Assume stream->buffer_size = 42 and I provide buffer = 1337. What
> happens? Does it copy 42 bytes (this is what your documentation
> suggests) or does it fail immediately?
It would copy 42 bytes, though I don't know what you mean with "buffer = 1337". I guess no driver will ever support 1338 buffers, the AC97 e.g. will probably use 32.

>>> Is there a way to update the data later? I'm thinking of a mixer that
>>> sent 30 seconds in advance to keep the CPU load low, but then the user
>>> hit the stop button.
>>
>> The stop button is handled by the application, thus it must make sure the mixer won't get the data 30 seconds in advance (I think; I've never written such an application).
> 
> You'll always want to provide some data in advance. The shorter your
> buffers are, the higher are the chances that you get dropouts. So the
> application can't make it too short. On the other, a stop button that
> works only with a delay isn't really acceptable either.
Hm... Anyone who knows how this is handled on Linux etc.?


Max