summaryrefslogtreecommitdiff
path: root/samples
diff options
context:
space:
mode:
authorOskar Schirmer <oskar@scara.com>2013-11-05 12:13:54 +0000
committerMark Brown <broonie@linaro.org>2013-11-06 09:41:57 +0000
commit68f9672b1388f0999d4087b72c3c80cf1c983fa2 (patch)
tree9335123e1d448d4ae0fce6eac3cdca91f760ff78 /samples
parent5a6e19bedb13522924f5ee72c1f65b0fb5d33bc0 (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 'samples')
0 files changed, 0 insertions, 0 deletions