Re: 'BATCH flag for USB' and 'ALSA Core Challenges' - Pierre-Louis Bossart

From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Takashi Sakamoto <o-takashi@sakamocchi.jp>,
	Liam Girdwood <liam.r.girdwood@linux.intel.com>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Cc: Takashi Iwai <tiwai@suse.de>, Mark Brown <broonie@kernel.org>
Subject: Re: 'BATCH flag for USB' and 'ALSA Core Challenges'
Date: Tue, 13 Oct 2015 11:01:48 -0500	[thread overview]
Message-ID: <561D2AEC.400@linux.intel.com> (raw)
In-Reply-To: <561D10AD.7010800@sakamocchi.jp>

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 :-)

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