[Portaudio] Multi-channel devices glitching in CoreAudio

[Ross Bencina]

Hi Gabriel

> Yes, I think this code was actually correct: (size1+size2) == framesProcessed * inChan * flsz). 

Are you sure? Have you checked it with an assert? My reading of the code is that  (size1+size2) >= framesProcessed * inChan * flsz 

Thats >= not ==

size1+size2 is the total available data to read in the ring buffer, but the buffer processor only consumes framesProcessed (which could be less than the total amount of data available in the ring buffer). If you advance the read index by the available data amount (size1+size2) and this is greater than framesProcessed you would get glitches.

I could be wrong, it's late here...

Ross.



  ----- Original Message ----- 
  From: Gabrielle Hucknall 
  To: Portaudio Mailing List 
  Sent: Tuesday, October 19, 2010 11:26 PM
  Subject: Re: [Portaudio] Multi-channel devices glitching in CoreAudio


  Hi Ross, 


  Sorry it's taken me a while to get back to you.


  Yes, I think this code was actually correct: (size1+size2) == framesProcessed * inChan * flsz). It was the ringbuffer element size being set to 1 which confused me originally.


  GH






  On 16 October 2010 02:40, Ross Bencina <rossb-lists at audiomulch.com> wrote:

    Gabriel

    Did you make this change I suggested on 13/10?

    ->>>

    > Gabriel wrote:
    > 
    >> > One other thing you should try is changing line 2111 to:
    >> > PaUtil_AdvanceRingBufferReadIndex(&stream->inputRingBuffer, 
    >> > framesProcessed)
    >>
    >> Tried this and no luck: I think that adding the bytes processed rather 
    >> than the frames processed is right because the RingBuffer is initialized 
    >> with an element size of 1?
    > 
    > Ah OK, in that case it should be:
    > 
    > PaUtil_AdvanceRingBufferReadIndex(&stream->inputRingBuffer, framesProcessed 
    > * flsz * inChan );

    That is definitely what the code should be.

    Ross.

      ----- Original Message ----- 
      From: Gabrielle Hucknall 
      To: Portaudio Mailing List 
      Sent: Friday, October 15, 2010 6:39 PM
      Subject: Re: [Portaudio] Multi-channel devices glitching in CoreAudio


      Hi Bjorn,

      Thank-you for your help so far with this. I tried to alter the code around pa_mac_core:1637 as you suggested but it didn't seem to make a difference. However, I am not 100% sure that I've made the exact change you intended, so a patch would be very useful.


      Some other facts gleaned from experimenting this week:


      * Reverting to revision 1345 doesn't resolve the problem.


      * Increasing the size allocated for the ring buffer, AND removing the initial call to pa_AdvanceRingBuffer around line 1637 does result in a recognisable signal, but some occasional glitching remains.


      I hope that this has been helpful, please let me know if I can provide any more information or details


      GH








      On 12 October 2010 16:42, Bjorn Roche <bjorn at xowave.com> wrote:


        On Oct 12, 2010, at 11:33 AM, Ross Bencina wrote:


          Gabriel wrote:


            > One other thing you should try is changing line 2111 to:
            > PaUtil_AdvanceRingBufferReadIndex(&stream->inputRingBuffer, > framesProcessed)

            Tried this and no luck: I think that adding the bytes processed rather than the frames processed is right because the RingBuffer is initialized with an element size of 1?


          Ah OK, in that case it should be:

          PaUtil_AdvanceRingBufferReadIndex(&stream->inputRingBuffer, framesProcessed * flsz * inChan );

          (sorry, trying to execute code in my head doesn't always work as expected...)

          I'm still not sure why the split buffer case is getting hit though



        Correct, I think, but the split buffer may be getting hit because... 



          Later you wrote:


            I just tried to comment out the line at pa_mac_core.c ~1637:




                    if( stream->outputUnit )
                       PaUtil_AdvanceRingBufferWriteIndex( &stream->inputRingBuffer, ringSize / RING_BUFFER_ADVANCE_DENOMINATOR );


          Well, this *should* be OK if the other code is working properly...




        ringSize / RING_BUFFER_ADVANCE_DENOMINATOR is not guaranteed to be a multiple of (flsz * inChan). You can pop in an assert for that to see if that's the problem. The fix would be a little integer arithmetic like this:

        long advance = ringSize / RING_BUFFER_ADVANCE_DENOMINATOR ;
        advance = ( advance / (flsz * inChan) ) * ((flsz * inChan)) ;
        PaUtil_AdvanceRingBufferWriteIndex( &stream->inputRingBuffer, advance );

        I will patch it if that turns out to be a problem. 


               bjorn

        -----------------------------
        Bjorn Roche
        XO Audio, LLC
        Audio Software & Digital Audio Consulting
        http://www.xoaudio.com
        http://blog.bjornroche.com

        _______________________________________________

        Portaudio mailing list
        Portaudio at music.columbia.edu
        http://music.columbia.edu/mailman/listinfo/portaudio





--------------------------------------------------------------------------


      _______________________________________________
      Portaudio mailing list
      Portaudio at music.columbia.edu
      http://music.columbia.edu/mailman/listinfo/portaudio


    _______________________________________________
    Portaudio mailing list
    Portaudio at music.columbia.edu
    http://music.columbia.edu/mailman/listinfo/portaudio





------------------------------------------------------------------------------


  _______________________________________________
  Portaudio mailing list
  Portaudio at music.columbia.edu
  http://music.columbia.edu/mailman/listinfo/portaudio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://music.columbia.edu/pipermail/portaudio/attachments/20101020/79349c2e/attachment-0001.html>