ssfrr / AudioIO.jl

[UNMAINTAINED] - Simple Audio IO in Julia
MIT License
61 stars 24 forks source link

Warning: libportaudio: Input overflowed #39

Closed staticfloat closed 9 years ago

staticfloat commented 9 years ago

Whenever I start something playing, my julia console gets flooded with warning messages:

WARNING: libportaudio: Input overflowed

What can I do to stop that from happening?

ssfrr commented 9 years ago

There are two answers to that. One is to figure out why the audio task isn't keeping up with the frame rate (which is the underlying cause). The other is to just get rid of the warning messages (if you're not actually hearing dropouts).

The latest master disables those warnings by default, so if they're not actually causing issues that will fix the annoyance.

There seem to be some issues on some machines keeping up with the deadlines, so any details you have on Julia version and system would be helpful, particularly if you see the warnings in some configurations and not others.

staticfloat commented 9 years ago

Sorry, I realize that issue was a little light on details. Here's my system information:

julia> versioninfo()
Julia Version 0.3.2
Commit 8227746* (2014-10-21 22:05 UTC)
Platform Info:
  System: Darwin (x86_64-apple-darwin14.0.0)
  CPU: Intel(R) Core(TM) i5-4258U CPU @ 2.40GHz
  WORD_SIZE: 64
  BLAS: libopenblas (NO_AFFINITY HASWELL)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

This is on a macbook pro running OSX 10.10, and Julia 0.3.2. The thing I found most surprising is that it's complaining about the Input overflowing, not the Output (It does complain about the Output once, but after that initial hiccup, things are fine). This happens even when all I've done is:

using AudioIO
osc1 = SinOsc(440)
play(osc1)

It also continues after a stop(osc1). The sound is perfect, no underruns.

ssfrr commented 9 years ago

Hmm, I'm still on 10.9, I wonder if that's related. Can you try disabling AppNap for Julia?

I'm not that surprised about input/output overflowing, as the stream is duplex even if the first thing you play is only playback. Also the stream stays open even if there aren't any active AudioNodes, which is why you see the warnings continue to pop up. I've thought about maybe closing the stream when there aren't any audio nodes, but I want to be able to create and destroy nodes with minimal latency, which is why I'm defaulting to keeping things open.

staticfloat commented 9 years ago

Hmmm. I'm building from source, so I don't have a .app, and thus I don't know how to disable AppNap.

ssfrr commented 9 years ago

Looks like you can disable globally by running:

defaults write NSGlobalDomain NSAppSleepDisabled -bool YES

which can be later reversed with

defaults write NSGlobalDomain NSAppSleepDisabled -bool NO

You can check whether AppNap is enabled from the Activity Monitor

(source: http://www.cnet.com/how-to/how-to-disable-app-nap-system-wide-on-os-x-mavericks/)

staticfloat commented 9 years ago

I just confirmed that appnap doesn't affect this.

However, isn't this expected? Looking at this problem after some good sleep, I'm not reading from the input at all, so of COURSE it's overflowing! I think the true solution here is to just checkout master where everything behaves as expected. Thanks for your time. ;)

ssfrr commented 9 years ago

You're not reading from the input, but the underlying AudioIO Task is (it's just not being used for anything in your render chain). Updating to master isn't really solving the issue, it's just silencing the warning.

Regardless, it's probably the same issue as #29, so I'll leave it closed. I'll be trying to track down a few more Macs to try it on to see if I can nail down why some machines don't seem to be able to keep up the audio task.