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

[Pierre-Louis Bossart]

On 10/13/15 9:09 AM, 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?
>
> 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 idea was to rely on the new hw_params field that was tentatively 
called max_burst to report how much data is pulled/pushed at once by the 
hardware. If the driver indicated that it handles a complete period this 
would provide the same functionality as the BATCH flag that could then 
be deprecated. I will try to post patches soon.

>
>> ALSA Core Challenges:
>> ======================
>> - ALSA Core locking is complicated. Core code is quite difficult to
>> understand.
>> - PCM linking makes things complex
>> - Add documentation for locks.
>>   - Controls can be hidden in UI tools through iface_cards.
>>   - DPCM hidden PCMs should not be shown in usermode, hide them from
>> Usermode
>
> The third item mentions about 'iface_cards', while there'no such
> structure in kernel/userspace.
> What's it and what is the 'UI tools'? Does it means to produce some GUI
> widget?

The idea was that if there is a new interface used instead of 'mixer' 
then the new controls would not be made visible to UI tools that look 
for the mixer interface. But of course a new tool looking for the new 
iface would be able to display everything so it's only a work-around.

> Sorry just to take my questions but I'm not a participant of the meeting...

we certainly hope you can join next time :-)