Re: 'BATCH flag for USB' and 'ALSA Core Challenges'

["Alexander E. Patrakov" <patrakov@gmail.com>]

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. Please see this email that 
explains the intended meaning of the flags:

http://mailman.alsa-project.org/pipermail/alsa-devel/2015-June/093750.html

>
> 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.

-- 
Alexander E. Patrakov
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel