All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve deRosier <derosier@pianodisc.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@lists.sourceforge.net
Subject: Re: negative timestamps on pcm?!?
Date: Tue, 21 Oct 2003 10:05:26 -0700	[thread overview]
Message-ID: <3F956756.607@pianodisc.com> (raw)
In-Reply-To: <s5hvfqidh15.wl@alsa2.suse.de>

> 
> when the state is OPEN, these values are bogus, since snd_pcm_status()
> returns immediately without putting the values.
> 

So, alsa writes bogus data to the proc entries?  Maybe it shouldn't 
write bad data, just leave the spots blank, initilize with 0's or 
something else?

>>-----
>>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.
> 

What restriction is that?

>>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.

Right, the values make no sense, but I think we've explained that away 
now.  So, what is causing alsa to eventually stop playing right?  Yes, 
that's not exactly a fair question... where should we start looking? 
Maybe a mutex, race condition, or an off-by-one error somewhere?

> 
> which version of ALSA driver are you using?
> 

Driver: 0.9.7c
Library: 0.9.7
(retrieved from the website just a few days ago)

Thanks,
- Steve



-------------------------------------------------------
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

  reply	other threads:[~2003-10-21 17:05 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
2003-10-21 17:05   ` Steve deRosier [this message]
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=3F956756.607@pianodisc.com \
    --to=derosier@pianodisc.com \
    --cc=alsa-devel@lists.sourceforge.net \
    --cc=tiwai@suse.de \
    /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.