At Tue, 21 Oct 2003 22:00:33 -0400, Manuel Jander wrote: > > Hallo, > > There really something wrong. > > 718, max jitter = 8192): wrong interrupt acknowledge? > ALSA sound/core/pcm_lib.c:157: Unexpected hw_pointer value (stream = 0, > delta: -297, max jitter = 1024): wrong interrupt acknowledge? > ALSA sound/core/pcm_lib.c:157: Unexpected hw_pointer value (stream = 0, > delta: -722, max jitter = 8192): wrong interrupt acknowledge? > ALSA sound/core/pcm_lib.c:157: Unexpected hw_pointer value (stream = 0, > delta: -301, max jitter = 1024): wrong interrupt acknowledge? > ALSA sound/core/pcm_lib.c:157: Unexpected hw_pointer value (stream = 0, > delta: -726, max jitter = 8192): wrong interrupt acknowledge? > ALSA sound/core/pcm_lib.c:157: Unexpected hw_pointer value (stream = 0, > delta: -305, max jitter = 1024): wrong interrupt acknowledge? > ALSA sound/core/pcm_lib.c:157: Unexpected hw_pointer value (stream = 0, > delta: -730, max jitter = 8192): wrong interrupt acknowledge? > > How do you explain this ???
the hwptr is not updated properly. > > At first i would vote for eliminating that "-" since it leads one to > think into negative deltas, that really dones make any sense. yes, it's a bit confusing, but minus makes sense because the delta value (= new - old) is in fact negative. in the calculation, (old - new) is used to avoid the sign conversion, though. > And why is the "max jitter" changing all the time ? do they come from the same stream? anyway, your code above is too old now. the line doesn't correspond to the latest version. so i cannot say exactly. > And the delta is > smaller than the "max jitter", so why should it complain ?? it's not the comparison like delta > max_jitter. it's the check for the overlap of the ring buffer. the pcm routine tries to detect whether the hwptr moved across the ring buffer boundary. and for that, delta > -max_jitter is performed. since delta in the code is (old - new), the comparison is reversed. > I just want to know if me soundboard is smoking crack or what ? if this comes from snd_pcm_update_hw_ptr_interrupt(), then it's a serious problem. if it comes from snd_pcm_update_hw_ptr(), it's mostly harmless, as i wrote in the previous post. the alsa pcm tries to update hwptr often, not only when the interrupts are issued and snd_pcm_period_elapsed() is called. (e.g. at each read or write call, or when RESET, FORWARD, REWIND, HWSYNC or DELAY ioctl is used.) this problem happens likely in such a case, especially when interrupt handling is sloppy, or pointer callback is not reliable. 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 _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
