From: bugtrack@alsa-project.org
To: alsa-devel@alsa-project.org
Subject: [ALSA - driver 0000951]: Fix bugs with early IRQs mishandling, missing silence fill, and wrong timing calculations
Date: Thu, 3 Mar 2005 15:03:19 +0100 [thread overview]
Message-ID: <03cbaa3ba5f0f8b49c3fa26bf3cc2829@bugtrack.alsa-project.org> (raw)
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=951>
======================================================================
Reported By: charles_levert
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 951
Category: CORE - pcm
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution:
Kernel Version: 2.4.22
======================================================================
Date Submitted: 02-28-2005 21:26 CET
Last Modified: 03-03-2005 15:03 CET
======================================================================
Summary: Fix bugs with early IRQs mishandling, missing
silence fill, and wrong timing calculations
Description:
A patch is forthcoming.
Here is the text from the patch preamble.
This patch is against alsa-driver-1.0.8.
It covers:
alsa-kernel/core/pcm_lib.c
alsa-kernel/include/pcm.h
alsa-kernel/core/pcm_native.c
alsa-kernel/core/oss/pcm_oss.c
The main changes are in the first listed file.
An original bug description was filed
under "[ALSA - driver] PCI - cmipci":
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=946>
since the problems were first observed on this hardware.
The patch fixes the following problems:
-- Properly handle early IRQs in
snd_pcm_update_hw_ptr_interrupt() in pcm_lib.c.
This does occur, at least with CMI8738MC6 hardware.
This bug had a major impact that caused the DMAs
to run for too long and irritating noise to be
heard at the end of playback.
-- Properly compute estimated time of next interrupt
in snd_pcm_update_hw_ptr_interrupt() in pcm_lib.c;
this is no longer done with a
"... % runtime->period_size" kludge (which didn't
even attempt to round to nearest instead of merely
truncating).
-- Test whether hw_avail is big enough to handle
the next runtime->period_size in
snd_pcm_update_hw_ptr_post() in pcm_lib.c,
otherwise call snd_pcm_tick_prepare() to
tentatively set up a timer if needed (to be able
to take earlier action in that case).
-- Centralize all folding of values with regard to
runtime->boundary in the new snd_pcm_next_buf()
function in pcm_lib.c.
All relevant values are now systematically in
coherent synchronization without resorting to the
ugly and error-prone "value %= runtime->boundary"
kludge all over the place; unobvious wrapping
conditions testing is no longer needed in these
places.
A safe zone worth one runtime->buffer_size is now
kept on the left side of the operating interval,
just like it was the case for the right side;
this is necessary for proper simplified operation.
-- Direct manipulations of values with respect to
runtime->boundary needed to be brought in line
with new proper practices (and thus simplified)
in pcm.h, pcm_lib.c, pcm_native.c, and pcm_oss.c.
-- Isolate the second part of
snd_pcm_playback_silence() in the new
snd_pcm_playback_silence_fill() function in
pcm_lib.c.
This makes the code more readable since the
task this performs should not be confused with
what is done in the remaining first part of
snd_pcm_playback_silence().
The isolated code is unchanged.
-- Rewrite the remaining first part of
snd_pcm_playback_silence() to properly handle all
situations, including computing minimum silence
insertion even when "runtime->silence_size == 0".
This is needed for proper operation of the aplay
program, for one, and is much more forgiving on the
user; insertion of silence samples in user space
was always useless and a wrong solution anyway (but
user space specification of kernel space silence
insertion is useful and still very much supported).
The code is now much more straightforward to read.
Updates of runtime->control->appl_ptr (due
to the user writing samples) and updates to
runtime->status->hw_ptr (due to the audio hardware
consuming samples) are now _both_ properly
accounted for in all cases; the new code makes
this much more obvious.
-- All calls to snd_pcm_playback_silence() in
pcm_lib.c and pcm_native.c must no longer be under
the "runtime->silence_size > 0" condition.
-- Properly perform rounded-up integer division in
snd_pcm_system_tick_set() in pcm_lib.c.
This only had a minor impact.
-- Properly compute distance to next interrupt in
snd_pcm_tick_prepare() in pcm_lib.c; again, avoid
using any "... % runtime->period_size" kludge.
-- The usage of runtime->rate in
snd_pcm_tick_prepare() in pcm_lib.c was incorrect,
regarless of other changes.
The impact was that the timer was systematically
set to 1 single tick when it needed to be set to
typically hundreds of ticks.
-- The usage of runtime->sleep_min in
snd_pcm_tick_prepare() in pcm_lib.c was incorrect,
regarless of other changes.
The impact was that the number of ticks for
the timer was not properly adjusted up to what
sleep_min is documented to mean, when needed.
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
related to 0000946 Early playback DMA IRQ with CMI8738MC6 ...
======================================================================
----------------------------------------------------------------------
charles_levert - 03-03-05 14:37
----------------------------------------------------------------------
Attached file "early-irqs.patch" is hereby obsoleted.
It is replaced by the following four patches:
-- "hz-int-div.0b03.patch":
Fix rounded-up integer division bug.
-- "rate-sleep-ticks.0b03.patch":
Fix bugs with usage of runtime->tick_time.
-- "appl_ptr-boundary.0b03.patch":
Fix bugs with incorrectly wrapped appl_ptr.
-- "early-irqs.0b03.patch":
Fix bugs with early IRQs mishandling, missing
silence fill, and wrong timing calculations.
The bulk of changes can be found in the last patch, but
their number has been significantly reduced in some places.
E.g., snd_pcm_update_hw_ptr() is no longer modified and
snd_pcm_update_hw_ptr_interrupt() is much less modified.
The existing boundary-rounding intervals are no longer
changed so user space should not show the possibility of
being adversely affected.
The OSS changes are also no longer required.
----------------------------------------------------------------------
perex - 03-03-05 15:03
----------------------------------------------------------------------
It seems that hz-int-div.0b03.patch and rate-sleep-ticks.0b03.patch
contains same patch but different description....
Issue History
Date Modified Username Field Change
======================================================================
02-28-05 21:26 charles_levert New Issue
02-28-05 21:26 charles_levert Kernel Version => 2.4.22
02-28-05 21:29 charles_levert File Added: early-irqs.patch
03-01-05 09:36 perex Relationship added related to 0000946
03-01-05 09:40 perex Note Added: 0003755
03-01-05 11:15 charles_levert Note Added: 0003757
03-02-05 09:22 Clemens LadischNote Added: 0003761
03-02-05 13:01 charles_levert Note Added: 0003768
03-02-05 13:39 perex Note Added: 0003771
03-02-05 14:53 charles_levert Note Added: 0003776
03-03-05 14:21 charles_levert File Added: hz-int-div.0b03.patch
03-03-05 14:22 charles_levert File Added: rate-sleep-ticks.0b03.patch
03-03-05 14:23 charles_levert File Added: appl_ptr-boundary.0b03.patch
03-03-05 14:23 charles_levert File Added: early-irqs.0b03.patch
03-03-05 14:37 charles_levert Note Added: 0003786
03-03-05 15:03 perex Note Added: 0003787
======================================================================
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
next reply other threads:[~2005-03-03 14:03 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-03 14:03 bugtrack [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-03-22 1:51 [ALSA - driver 0000951]: Fix bugs with early IRQs mishandling, missing silence fill, and wrong timing calculations bugtrack
2005-03-18 17:12 bugtrack
2005-03-17 23:07 bugtrack
2005-03-04 10:57 bugtrack
2005-03-04 10:00 bugtrack
2005-03-04 5:26 bugtrack
2005-03-04 3:46 bugtrack
2005-03-04 2:34 bugtrack
2005-03-03 19:30 bugtrack
2005-03-03 15:05 bugtrack
2005-03-03 14:52 bugtrack
2005-03-03 14:34 bugtrack
2005-03-03 13:37 bugtrack
2005-03-02 13:53 bugtrack
2005-03-02 12:39 bugtrack
2005-03-02 12:01 bugtrack
2005-03-02 8:22 bugtrack
2005-03-01 10:15 bugtrack
2005-03-01 8:40 bugtrack
2005-03-01 8:36 bugtrack
2005-02-28 20:26 bugtrack
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=03cbaa3ba5f0f8b49c3fa26bf3cc2829@bugtrack.alsa-project.org \
--to=bugtrack@alsa-project.org \
--cc=alsa-devel@alsa-project.org \
/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