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
next prev parent reply other threads:[~2015-10-13 16:01 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-12 13:49 [Minutes] ELCE Audio mini conf Liam Girdwood
2015-10-12 15:30 ` Jaroslav Kysela
2015-10-12 20:59 ` Splitting out controls James Cameron
2015-10-13 7:07 ` David Henningsson
2015-10-13 8:27 ` Keyon
2015-10-13 14:55 ` Pierre-Louis Bossart
2015-10-13 15:56 ` David Henningsson
2015-10-13 16:08 ` Pierre-Louis Bossart
2015-10-16 6:41 ` David Henningsson
2015-10-16 14:49 ` Pierre-Louis Bossart
2015-10-16 15:24 ` Richard Fitzgerald
2015-10-30 2:48 ` Mark Brown
2015-10-16 15:28 ` Takashi Iwai
2015-10-14 18:20 ` Liam Girdwood
2015-10-16 15:35 ` Richard Fitzgerald
2015-10-16 16:00 ` Takashi Iwai
2015-10-16 16:31 ` Richard Fitzgerald
2015-10-16 17:00 ` Takashi Iwai
2015-10-17 15:54 ` Pierre-Louis Bossart
2015-10-17 16:02 ` Takashi Iwai
2015-10-18 6:41 ` Ricard Wanderlof
2015-10-30 2:57 ` Mark Brown
2015-10-17 16:25 ` Alexander E. Patrakov
2015-10-30 2:50 ` Mark Brown
2015-10-30 2:36 ` Mark Brown
2015-10-30 8:36 ` David Henningsson
2015-10-30 8:53 ` James Cameron
2015-10-30 9:04 ` David Henningsson
2015-11-01 2:45 ` Mark Brown
2015-10-13 14:09 ` 'BATCH flag for USB' and 'ALSA Core Challenges' Takashi Sakamoto
2015-10-13 14:44 ` Alexander E. Patrakov
2015-10-18 3:22 ` Takashi Sakamoto
2015-10-13 16:01 ` Pierre-Louis Bossart [this message]
2015-10-14 12:27 ` Liam Girdwood
2015-10-22 17:10 ` [Minutes] ELCE Audio mini conf Mark Brown
2015-10-22 17:14 ` DP hotplug on USB C Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=561D2AEC.400@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=liam.r.girdwood@linux.intel.com \
--cc=o-takashi@sakamocchi.jp \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.