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