From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: pl bossart <bossart.nospam@gmail.com>
Cc: "Koul, Vinod" <vinod.koul@intel.com>,
"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
Patrick Lai <plai@codeaurora.org>,
alsa-devel <alsa-devel@alsa-project.org>
Subject: Re: Compressed Audio Playback/Capture through ALSA framework
Date: Thu, 17 Mar 2011 18:25:18 +0000 [thread overview]
Message-ID: <20110317182518.GI31411@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <AANLkTiknu+TvXADvbt3egRcSmTjmv2+BScfWGNyCTkjr@mail.gmail.com>
On Thu, Mar 17, 2011 at 09:27:02AM -0500, pl bossart wrote:
> Wow. Run-time changes and discoverability? This sounds wild. what type
> of solutions are we talking about here?
> All the DSP implementations I've seen are pretty dumb, the firmware is
> downloaded at the request of the host when a specific service is
> requested; discoverability isn't an issue since the driver and
> possibly user-space know what's been downloaded and how the downloaded
> parts interact with the rest of the firmware.
Having the driver figure out what's going on isn't usually much of an
issue, it's letting the application know about the configuration that's
available. In situations where the DSP can support flexible routing
(eg, if it's got multiple audio interfaces and can route or mix between
them and also to and from the CPU) with per-flow algorithm selection it
gets unmanagable if you try to show everything possible via the current
ALSA APIs. Things get worse the more algorithms and so on the DSP can
support.
next prev parent reply other threads:[~2011-03-17 18:25 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-15 18:31 Compressed Audio Playback/Capture through ALSA framework Patrick Lai
2011-03-15 20:40 ` Eliot Blennerhassett
2011-03-15 20:52 ` [alsa-devel] " pl bossart
2011-03-15 23:28 ` Patrick Lai
2011-03-16 7:21 ` [alsa-devel] " Clemens Ladisch
2011-03-16 7:23 ` Jaroslav Kysela
2011-03-16 22:08 ` Patrick Lai
2011-03-17 7:39 ` [alsa-devel] " Clemens Ladisch
2011-03-16 10:38 ` Mark Brown
2011-03-16 10:59 ` Koul, Vinod
2011-03-16 11:56 ` Mark Brown
2011-03-16 12:17 ` Koul, Vinod
2011-03-16 17:52 ` pl bossart
2011-03-16 17:53 ` Mark Brown
2011-03-16 18:00 ` pl bossart
2011-03-16 18:08 ` Mark Brown
2011-03-17 2:21 ` Koul, Vinod
2011-03-17 5:00 ` Patrick Lai
2011-03-17 11:54 ` Mark Brown
2011-03-17 14:27 ` pl bossart
2011-03-17 18:25 ` Mark Brown [this message]
2011-03-17 19:16 ` pl bossart
2011-03-17 20:16 ` Mark Brown
2011-03-17 21:19 ` Patrick Lai
2011-03-17 21:25 ` Mark Brown
2011-03-18 16:03 ` pl bossart
2011-03-22 13:01 ` Mark Brown
2011-03-17 5:32 ` Asus E35M1-M Pro and Realtek AL887-VD - no love from ALSA for Sourround Wojciech Myrda
2011-03-17 21:55 ` Paul Menzel
2011-03-20 10:13 ` Wojciech Myrda
2011-03-18 2:22 ` Compressed Audio Playback/Capture through ALSA framework Raymond Yau
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=20110317182518.GI31411@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=bossart.nospam@gmail.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=plai@codeaurora.org \
--cc=vinod.koul@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).