From: Mark Brown <broonie@opensource•wolfsonmicro.com>
To: Jon Smirl <jonsmirl@gmail•com>
Cc: John Bonesio <bones@secretlab•ca>,
alsa-devel@alsa-project•org, linuxppc-dev@lists•ozlabs.org,
lrg@slimlogic•co.uk
Subject: Re: [alsa-devel] [PATCH 2/6] ASoC/mpc5200: get rid of the appl_ptr tracking nonsense
Date: Thu, 12 Nov 2009 12:10:34 +0000 [thread overview]
Message-ID: <20091112121034.GA16661@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <9e4733910911111513w5423333cp6cf08ceec9a94ac3@mail.gmail.com>
On Wed, Nov 11, 2009 at 06:13:25PM -0500, Jon Smirl wrote:
> I don't think it is that much more work for ALSA to provide an
> accessible field indicating the end of valid data. It's already
> tracking appl_ptr. Appl_ptr just needs to be translated into a
> physical DMA buffer address and we've been making mistakes doing that
> translation.
I'm sure if you provide reasonable patches they'll get applied; it
doesn't seem likely that anyone else will work on this.
> On Wed, Nov 11, 2009 at 4:57 PM, Grant Likely <grant.likely@secretlab•ca> wrote
> > But it still wouldn't help a bit when the same latency occurs in the
> > middle of playback.
> The deterministic solution of tracking the end of valid data ensures
> that under run will be silent instead of playing invalid data.
In the middle of playback a sudden silence period is very noticable -
applications that expect data loss generally have some means to try to
cover it up since sudden silence is so noticable to the human ear. Mid
playback there's a bit more chance that random data from earlier in the
playback will be acceptable, and if the application has actually updated
the data but not got round to telling the driver about that yet then
even better.
I think you're getting too focused on the fact that there is a race
condition here since the consequences of race conditions are usually so
severe. There's always going to be some hardware for which there's a
degree of racyness (free running hardware has its own set of issues
here) so the system design takes this into account.
next prev parent reply other threads:[~2009-11-12 12:10 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-07 8:33 [PATCH 0/6] Fixups to MPC5200 ASoC drivers Grant Likely
2009-11-07 8:33 ` [PATCH 1/6] ASoC/mpc5200: Track DMA position by period number instead of bytes Grant Likely
2009-11-07 10:35 ` [alsa-devel] " Liam Girdwood
2009-11-07 16:50 ` Grant Likely
2009-11-07 8:34 ` [PATCH 2/6] ASoC/mpc5200: get rid of the appl_ptr tracking nonsense Grant Likely
2009-11-07 12:51 ` Jon Smirl
2009-11-07 13:04 ` Jon Smirl
2009-11-07 18:53 ` Grant Likely
2009-11-07 18:51 ` Grant Likely
2009-11-07 20:12 ` [alsa-devel] " Mark Brown
2009-11-11 16:38 ` Jon Smirl
2009-11-11 18:37 ` Mark Brown
2009-11-11 19:24 ` Grant Likely
2009-11-11 20:03 ` Mark Brown
2009-11-11 21:34 ` Jon Smirl
2009-11-11 21:57 ` Grant Likely
2009-11-11 23:13 ` Jon Smirl
2009-11-12 12:10 ` Mark Brown [this message]
2009-11-11 21:26 ` Jon Smirl
2009-11-07 8:34 ` [PATCH 3/6] ASoC/mpc5200: Improve printk debug output for trigger Grant Likely
2009-11-07 8:34 ` [PATCH 4/6] ASoC/mpc5200: add to_psc_dma_stream() helper Grant Likely
2009-11-07 12:33 ` [alsa-devel] " Mark Brown
2009-11-07 8:34 ` [PATCH 5/6] ASoC/mpc5200: fix enable/disable of AC97 slots Grant Likely
2009-11-07 8:34 ` [PATCH 6/6] ASoC/mpc5200: Add fudge factor to value reported by .pointer() Grant Likely
2009-11-07 18:11 ` [alsa-devel] " Mark Brown
2009-11-07 18:19 ` Grant Likely
2009-11-07 19:33 ` Mark Brown
2009-11-07 19:46 ` Grant Likely
2009-11-07 12:57 ` [alsa-devel] [PATCH 0/6] Fixups to MPC5200 ASoC drivers Mark Brown
2009-11-07 16:52 ` Grant Likely
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=20091112121034.GA16661@rakim.wolfsonmicro.main \
--to=broonie@opensource$(echo .)wolfsonmicro.com \
--cc=alsa-devel@alsa-project$(echo .)org \
--cc=bones@secretlab$(echo .)ca \
--cc=jonsmirl@gmail$(echo .)com \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=lrg@slimlogic$(echo .)co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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