From: Takashi Iwai <tiwai@suse.de>
To: derosier@pianodisc.com
Cc: alsa-devel@lists.sourceforge.net
Subject: Re: negative timestamps on pcm?!?
Date: Tue, 21 Oct 2003 12:25:10 +0200 [thread overview]
Message-ID: <s5hvfqidh15.wl@alsa2.suse.de> (raw)
In-Reply-To: <3F9423E9.2040409@pianodisc.com>
At Mon, 20 Oct 2003 11:05:29 -0700,
Steve deRosier wrote:
>
> All,
>
> We've noticed a problem with the newest version of Alsa while doing some
> stress testing of our devices. Basically, the scenerio is we're playing
> through a large library of .ogg files over the weekend. When we checked
> on the progress upon getting in on Monday, we discovered that the PCM
> had ceased playing, and our ogg player had started a ton of instances
> (one for each song it was supposed to play) and couldn't play on any of
> them. Looking at /proc/asound/card0/pcm0p/sub0/status:
> # cat status
> state: OPEN
> trigger_time: 642.000000000
> tstamp : -1071072720.-1071072332
> delay : 498
> avail : -1072507698
> avail_max : -1071072720
when the state is OPEN, these values are bogus, since snd_pcm_status()
returns immediately without putting the values.
> -----
> hw_ptr : 26942906
> appl_ptr : 26942906
they are real values.
i can't remember any reason of the restriction above.
i think it's ok to remove it.
> It seems that our ogg player is set to blocking behavior and each one is
> blocked on the call to open the pcm. The intrieging thing is the
> timestamp is negative. It jumped out that this just looks wrong!
>
> Hypothesis 1: After a really long time playing, the timestamp on the
> pcm wraps to negative. alsa can't handle this and blocks on the output.
> It's no longer running, but is still in an OPEN state so nothing else
> can open it. alsa should either use an unsigned value so large that it
> is impossable to overflow (???), use an unsigned and detect overflow and
> handle it gracefully, or use a signed value and detect the overflow/wrap
> and handle it.
> Hypothesis 2: We're barking up the wrong tree and the only thing wrong
> is that the proc entry is formmated poorly. (but even if that is the
> case, the problem still happens where after prolonged time alsa stops us).
at least, the values above make no sense.
which version of ALSA driver are you using?
Takashi
-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
next prev parent reply other threads:[~2003-10-21 10:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-20 18:05 negative timestamps on pcm?!? Steve deRosier
2003-10-21 10:25 ` Takashi Iwai [this message]
2003-10-21 17:05 ` Steve deRosier
2003-10-21 18:03 ` Takashi Iwai
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=s5hvfqidh15.wl@alsa2.suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@lists.sourceforge.net \
--cc=derosier@pianodisc.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.