From: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
To: Jon Hunter <jonathanh@nvidia.com>
Cc: alsa-devel@alsa-project.org, Sameer Pujar <spujar@nvidia.com>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
Liam Girdwood <liam.r.girdwood@linux.intel.com>
Subject: Re: [PATCH] ALSA: pcm: fix wait_time calculations
Date: Mon, 12 Jun 2023 16:28:36 +0200 [thread overview]
Message-ID: <ZIcrlOSlA233SC2y@ugly> (raw)
In-Reply-To: <76082a48-508b-e5cf-6ae0-66c265ecfdd7@nvidia.com>
On Mon, Jun 12, 2023 at 02:16:15PM +0100, Jon Hunter wrote:
>On 12/06/2023 13:18, Jon Hunter wrote:
>> On 05/04/2023 21:12, Oswald Buddenhagen wrote:
>>> ... in wait_for_avail() and snd_pcm_drain().
>>
>> Sorry for not catching this sooner, but I have just noticed that one of
>> our audio tests for Tegra is failing on v6.4-rc and bisect is pointing
>> to this commit. Reverting this on top of the current mainline fixes it.
>>
>If I enable the debug prints, I do see the following messages ...
>
> tegra-audio-graph-card sound: capture read timeout (DMA or IRQ trouble?)
>
yes, this is the kind of fallout one would expect from this change, as
it significantly shortened the effective timeout under most
circumstances.
first check that there isn't a genuine underlying bug, that is, that the
unusually slow timings match expectations.
if everything looks right, then properly codify the timeout in the
driver by setting substream->wait_time as required.
the lazy approach of more or less restoring the previous status quo
would be setting it to 10000 in the `open` callback.
fwiw, soc/sof sets it to 500, which may actually be a bad idea (it's
short enough that a very long period time would exceed it, if such is
permitted). and it's not obvious why it does that.
regards
next prev parent reply other threads:[~2023-06-12 14:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-05 20:12 [PATCH] ALSA: pcm: fix wait_time calculations Oswald Buddenhagen
2023-04-06 15:01 ` Takashi Iwai
2023-06-12 12:18 ` Jon Hunter
2023-06-12 13:16 ` Jon Hunter
2023-06-12 14:28 ` Oswald Buddenhagen [this message]
2023-06-12 16:03 ` Jon Hunter
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=ZIcrlOSlA233SC2y@ugly \
--to=oswald.buddenhagen@gmx.de \
--cc=alsa-devel@alsa-project.org \
--cc=jonathanh@nvidia.com \
--cc=liam.r.girdwood@linux.intel.com \
--cc=linux-tegra@vger.kernel.org \
--cc=spujar@nvidia.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 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.