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.