[Portaudio] Multi-channel devices glitching in CoreAudio

Ross Bencina rossb-lists at audiomulch.com
Fri Oct 15 21:40:46 EDT 2010


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://music.columbia.edu/pipermail/portaudio/attachments/20101016/0368e8c0/attachment.html>


More information about the Portaudio mailing list