From: Sameer Pujar <spujar@nvidia.com>
To: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Linux-ALSA <alsa-devel@alsa-project.org>,
Mark Brown <broonie@kernel.org>,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
jonathanh@nvidia.com
Subject: Re: More Generic Audio Graph Sound Card idea
Date: Fri, 21 Aug 2020 13:58:15 +0530 [thread overview]
Message-ID: <7ceb0e77-fdf5-dd62-f1f6-660c4ed43e89@nvidia.com> (raw)
In-Reply-To: <87imdczd4i.wl-kuninori.morimoto.gx@renesas.com>
Hi Morimoto-san,
...
>> If we encode use case information in DT, it would become regid and is
>> not flexible when the HW is giving us the all flexibility (at least in
>> my case). Thus may lead to complications. If there is a way to
>> configure PCM parameters from the user space it would help to simplify
>> things. Then DT can just describe the HW links.
> What kind of PCM parameters you want to get from user-space ?
I was referring to channels, rate, sample size for PCM parameters which
are part of hw_params(). Having these strictly defined in DT would limit
from using the same audio path for different configurations. So far used
mixer controls for overriding this info in hw_param(), but this idea is
dropped as per Mark's suggestion earlier. The requirement here is, some
components have the ability to alter these parameters. Subsequent
components in the audio path should me made aware of this.
For example, SRC (sample rate converter) can change 'rate' info coming
from hw_param(). Similarly 'mux/demux' can change channel info. Fixing
one set of configuration in DT will limit the usage. If this is
configurable from user space, then it would be lot more easier.
. . .
next prev parent reply other threads:[~2020-08-21 8:29 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-21 4:15 More Generic Audio Graph Sound Card idea Kuninori Morimoto
2020-08-21 5:26 ` Sameer Pujar
2020-08-21 7:14 ` Kuninori Morimoto
2020-08-21 8:28 ` Sameer Pujar [this message]
2020-08-21 13:02 ` Mark Brown
2020-09-25 1:43 ` Kuninori Morimoto
2020-09-25 19:22 ` Mark Brown
2020-09-25 20:04 ` Pierre-Louis Bossart
2020-09-25 20:10 ` Mark Brown
2020-09-25 20:50 ` Pierre-Louis Bossart
2020-08-21 7:11 ` Daniel Baluta
2020-08-21 7:25 ` Kuninori Morimoto
2020-08-21 7:33 ` Daniel Baluta
2020-08-21 11:47 ` Mark Brown
2020-08-21 12:18 ` Mark Brown
2020-08-24 0:25 ` Kuninori Morimoto
2020-08-24 6:25 ` Sameer Pujar
2020-08-25 0:59 ` Kuninori Morimoto
2020-08-25 3:11 ` Sameer Pujar
2020-08-25 5:13 ` Kuninori Morimoto
2020-08-25 5:42 ` Sameer Pujar
2020-08-25 6:35 ` Kuninori Morimoto
2020-08-26 6:46 ` Sameer Pujar
2020-08-27 1:18 ` Kuninori Morimoto
2020-08-27 1:36 ` Kuninori Morimoto
2020-09-03 23:51 ` Kuninori Morimoto
2020-09-09 11:33 ` Sameer Pujar
2020-08-21 15:49 ` Pierre-Louis Bossart
2020-10-13 4:50 ` Kuninori Morimoto
2020-10-15 14:32 ` Mark Brown
2020-10-15 23:04 ` Kuninori Morimoto
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=7ceb0e77-fdf5-dd62-f1f6-660c4ed43e89@nvidia.com \
--to=spujar@nvidia.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=jonathanh@nvidia.com \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=pierre-louis.bossart@linux.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).