[alsa-devel] 'BATCH flag for USB' and 'ALSA Core Challenges'

[Takashi Sakamoto]

Hi Alexander,

On Oct 13 2015 23:44, Alexander E. Patrakov wrote:
> 13.10.2015 19:09, Takashi Sakamoto wrote:
>> Hi,
>>
>> (If I were in ±0200、I would have joined in the meeting...)
>>
>> There're some interesting issues in the minutes. Would I request someone
>> more explaination about it?
>>
>>> BATCH flag for USB: Arun.
>>> =========================
>>>   - Flag does not respond to reality, lets deprecate it. no users.
>>>   - Dylan: need to know transfer size for CRAS (uses extra samples for
>>> buffering).
>>>   - BATCH flag means period size transfers, applications that use new
>>> granularity API can ignore batch flag. Pierre: to implement.
>> The first item said 'BATCH flag should be deprecated', while
>> BLOCK_TRANSFER flag is not mentioned. Are there some discussions about
>> the differences between these two flags?
> 
> There is no conspiracy here, just inaccurately-written minutes. The
> proposal to deprecate was about the BLOCK_TRANSFER flag (because
> currently it means absolutely othing and has no users), although I
> support deprecation of the BATCH flag too.

In my understanding, these two flags relate to calculating the number of
transferred PCM frames within a period. Although, just menthioning about
one of them is a bit strange to me. So I asked it. I have no interests
in the others.

> Please see this email that explains the intended meaning of the flags:
> 
> http://mailman.alsa-project.org/pipermail/alsa-devel/2015-June/093750.html

Anyway, I think it's a worse way to change the interfaces between
userspace without enough documentation.

>> I think the APIs suppose that the number of PCM frames in one
>> transferring is the same as the number of PCM frames in one period of
>> buffer. PCM device driver developers must always satisfy this principle?
>> Or the APIs allow them to implement such differences and present proper
>> value to userspace?
> 
> The intention is to provide driver developers the means to express the
> situation with the transfer size and pointer granularity in a useful
> manner, and two boolean flags just don't cut it. So some new API is needed.

Ditto.


Regards

Takashi Sakamoto