aboutsummaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorOskar Schirmer2013-11-05 12:13:54 +0000
committerMark Brown2013-12-02 11:13:19 +0000
commitd6437c14df89cb2df2bd9ef3692958d979b75d49 (patch)
treea6a600262ac631afa50876e58f2e6c4af8ecbd32 /README
parentfc7dc61d9a87011aaf8a6eb3144ebf9552adf5d2 (diff)
ASoC: fsl: imx-pcm-fiq: remove bogus period delta calculation
Originally snd_hrtimer_callback() used iprtd->period_time for some jiffies based estimation to determine the right moment to call snd_pcm_period_elapsed(). As timer drifts may well be a problem, this was changed in commit b4e82b5b785670b6 to be based on buffer transmission progress, using iprtd->offset and runtime->buffer_size to calculate the amount of data since last period had elapsed. Unfortunately, iprtd->offset counts in bytes, while runtime->buffer_size counts frames, so adding these to find some delta is like comparing apples and oranges, and eventually results in negative delta values every now and then. This is no big harm, because it simply causes snd_pcm_period_elapsed() being called more often than necessary, as negative delta is taken for a large unsigned value by implicit conversion rule. Nonetheless, the calculation is broken, so one would replace the runtime->buffer_size by its equivalent in bytes. But then, there are chances snd_pcm_period_elapsed() is called late, because calculating the moment for the elapsed period into delta is based against the iprtd->last_offset, which is not necessarily the first byte of the period in question, but some random byte which the FIQ handler left us with in r8/r9 by accident. Again, negative impact is low, as there are plenty of periods already prefilled with data, and snd_pcm_period_elapsed() will probably be called latest when the following period is reached. However, the calculation is conceptually broken, and we are best off removing the clever stuff altogether. snd_pcm_period_elapsed() is now simply called once everytime snd_hrtimer_callback() is run, which may not be most accurate, but at least this way we are quite sure we dont miss an end of period. There is not much extra effort wasted by superfluous calls to snd_pcm_period_elapsed(), as the timer frequency closely matches the period size anyway. Signed-off-by: Oskar Schirmer <oskar@scara.com> Signed-off-by: Mark Brown <broonie@linaro.org>
Diffstat (limited to 'README')
0 files changed, 0 insertions, 0 deletions