Additional buffering needed in several cases

[bjornroche]

Axel Roebel said:

I would like to jump in here. I recently tried portaudio cvs on linux with frames per buffer == 4096 and this worked fine. Compiling the same application with the same settings on mac os x I've got a lot of clicks. It is a simple file player, so latency is not a problem. After having investigated the code in portaudio it seems that the mac os x implementation does not like large values of frames per buffer? Have you any comments on that?

Ross: Well I can't comment on why the OSX version behaves that way, but I can say that PortAudio should, wherever practical, be able to handle large user buffer sizes... perhaps PA is limiting the host buffer size? (erroneously) or perhaps CoreAudio? places some upper limit on the host buffer size -- in the latter case the fix is more complicated.

Bjorn: Axel, Sorry I missed your original posting. Yes, I have seen problems with using a value for FramesPerBuffer? that is significantly larger than the native block-size of the device on Mac OS X. There is nothing in the PA code (as far as I know) that causes this -- I believe it is an issue with CoreAudio?. CoreAudio?, which is pretty much designed for low-latency all the time operation, only works with two buffers, one for the sound card, and one for the application, so if your buffer is too big for the sound card to swallow in one bite, you're in trouble. This could be worked around internally by breaking up the buffers, or using a ring-buffer, but I don't think the extra work, computation, and latency would be worth it.

ross: In general I think it should be considered a bug in PortAudio if making the buffer size bigger creates instability. That said, with the current ASIO implementation you would probably see the same thing if the driver limited the buffer size to a small value, and you used a bigger host buffer -- the only solution I can think of is an extra processing thread, which seems like a reasonable (if more complex) solution... but one that hasn't been implemented as far as I know.

bjorn: I agree it's a bug, but I'm not sure the solution is worth it. I created a ticket so at least there's a record.

[bjornroche]

As has been noted for some time in the core audio notes file, Latency settings are often ignored. This is a bug in it's own right, but it might help resolve this issue to have additional buffering when higher latencies are requested. This will be non-trivial because CA itself provides no buffering beyond it's two-buffer system. See this thread for a discussion:

http://techweb.rfa.org/pipermail/portaudio/2007-August/007439.html

[bjornroche]

Small buffer sizes should also be handled better in the Core Audio implementation. At the moment, I believe the device buffer size is always matched to the requested buffer size, which may be too small for the system. A larger buffer size could be used, calculated based on the sample rate and the latency of the system, and smaller packets sent to the user, but that's not done ATM.