Re: [linux-audio-user] Again on sudden and occasional Jack crackling sound

Re: [linux-audio-user] Again on sudden and occasional Jack crackling sound

[Lee Revell]

On Tue, 2005-08-09 at 16:49 -0400, Paul Davis wrote:
> On Tue, 2005-08-09 at 22:17 +0000, Salvatore Di Pietro wrote:
> 
> > Moreover, using jack_bufsize, or resizing buffer within Ardour, causes 
> > complete muting of output sound (bit not clients death, as it was 
> > before), until I restart jack.
> > Notice that this "complete muting" only affects the output ports, i.e. I 
> > can continue recording with qarecord, or ardour, I just cannot hear (and 
> > monitor) anything anymore until I restart jack and its clients.
> 
> as far as we can tell, this is an ALSA (kernel) driver issue. it does
> not affect other backends, and does not affect (we think) every ALSA
> supported piece of h/w. it would be nice for it to be either fixed or at
> least tracked down conclusively.
> 

OK, here's an idea.  Say there was an off-by-one error or some other bug
in the ALSA middle layer that caused the reported value of the hardware
pointer to be off by one.  So snd_pcm_avail_update would report 64
frames available while there were actually 63.  If JACK gets scheduled
within the space of one frame (quite possible especially with the RT
kernel, it's a ~20us window at 48KHz) then we could overwrite the wrong
part of the buffer - a frame or two ahead of the hardware pointer.
AFAICT this would introduce a crackle, but no xruns would be reported.

Does this sound reasonable?

Lee



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Again on sudden and occasional Jack crackling sound

[Lee Revell]

On Tue, 2005-08-09 at 22:12 -0400, Lee Revell wrote:
> On Tue, 2005-08-09 at 16:49 -0400, Paul Davis wrote: 
> > as far as we can tell, this is an ALSA (kernel) driver issue. it does
> > not affect other backends, and does not affect (we think) every ALSA
> > supported piece of h/w. it would be nice for it to be either fixed or at
> > least tracked down conclusively.
> > 
> 
> OK, here's an idea.  Say there was an off-by-one error or some other bug
> in the ALSA middle layer that caused the reported value of the hardware
> pointer to be off by one.  So snd_pcm_avail_update would report 64
> frames available while there were actually 63.  If JACK gets scheduled
> within the space of one frame (quite possible especially with the RT
> kernel, it's a ~20us window at 48KHz) then we could overwrite the wrong
> part of the buffer - a frame or two ahead of the hardware pointer.
> AFAICT this would introduce a crackle, but no xruns would be reported.

Hmm, I think I might be on to something.  This sounds like the exact
same bug, but they can produce it without JACK:

http://www.winehq.org/hypermail/wine-patches/2005/08/0173.html

The WINE developer had the same idea:

      //* /*FIXME*/: snd_pcm_mmap_hw_ptr() should not be accessed by a user app. *//
      //*        It will NOT return what why want anyway. *//
      hw_ptr = _snd_pcm_mmap_hw_ptr(wwo->pcm);

  I thought, maybe it is not returning the correct information for 
  GetPosition, so that is why the crackling exists, since new samples are 
  off-position from what they should be in order to guarantee a smooth 
  sound

So in both cases we're operating in mmap mode and ALSA is returning a
slightly incorrect hardware pointer which leads to crackling.

Lee

Re: [linux-audio-user] Again on sudden and occasional Jack crackling sound

[Lee Revell]

On Wed, 2005-08-10 at 15:38 -0400, Lee Revell wrote:
> So in both cases we're operating in mmap mode and ALSA is returning a
> slightly incorrect hardware pointer which leads to crackling.

Another thing to find out is whether this bug is more common when using
sample rates like 44100, 88200, where the number of periods per buffer
is not an integer.

Lee



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf