"Output underflowed" error

[flpf]

Hi,

I receive an "output underflowed" error message in the julia-REPL when using the AudioIO.jl package. The play and stop commands work as expected but after several seconds after the play()-function finishes, i get the following warning over and over:

julia> play(knockACc./maximum(abs(knockACc)));

julia> ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
WARNING: libportaudio: Output underflowed
julia> plot(knockACc)
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
WARNING: libportaudio: Output underflowed
1-element Array{Any,1}:
 PyObject <matplotlib.lines.Line2D object at 0x7f9e660a4390>

julia> ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
WARNING: libportaudio: Output underflowed
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
WARNING: libportaudio: Output underflowed
.... you see where this is going...

I'm not sure if this has something to do with my audio setup or a portaudio api-call of the package.

I updated all packages. My julia-version is:

julia> versioninfo()
Julia Version 0.4.0-dev+5127
Commit 6277015* (2014-09-05 03:57 UTC)
DEBUG build
Platform Info:
  System: Linux (x86_64-unknown-linux-gnu)
  CPU: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

[shashi]

Yeah, I get this pretty consistent on the latest 0.4.0 as well.

[ssfrr]

What version of portaudio and your ALSA packages are you using?

Are the messages coming out once in a while, or spitting continuously?

[flpf]

My ALSA-version is:

cat /proc/asound/version 
Advanced Linux Sound Architecture Driver Version k3.16.1-1-ARCH.

and my portaudio version is:

PortAudio V19-devel (built Jan 31 2014 21:19:35)%

Sometimes, the error message is printed continuously every ten to twenty seconds and sometimes its printed only after evaluating an instruction in the REPL.
Besides that nasty error message the package works like a charm. No sound drop outs or total silence as I sometimes experienced in earlier versions.

[ssfrr]

Hmm, I don't see this on my machine so I'm trying to nail down what the difference is.

@shashi - you mentioned you see it on 0.4, does that mean you're seeing it on Julia 0.4 but not 0.3? Do you have specific commits you can provide for when it does or doesn't happen? If so and you have time for a bisect it would be awesome, but if you can just provide the endpoints I can at least check if I can reproduce.

@flpf - I have a somewhat older version of ALSA, so that's a possibility. Maybe I'll upgrade my linux machine soon, as I'm still running Ubuntu 12.04 LTS.

I'm also running portaudio V19-devel (though built somewhat later)

For reference:

Advanced Linux Sound Architecture Driver Version k3.11.0-26-lowlatency.
PortAudio V19-devel (built Oct  8 2012 16:37:35)

I also just built the latest Julia master and I'm still not seeing this issue.

   _       _ _(_)_     |  A fresh approach to technical computing
  (_)     | (_) (_)    |  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "help()" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.4.0-dev+308 (2014-08-22 17:29 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit ac7ac0b* (37 days old master)
|__/                   |  x86_64-linux-gnu

julia> using AudioIO

julia> play(SinOsc(220)*0.1);
INFO: Initializing PortAudio. Expect errors as we scan devices
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
ALSA lib audio/pcm_bluetooth.c:1529:(bluetooth_parse_config) Unknown field slave
ALSA lib audio/pcm_bluetooth.c:1529:(bluetooth_parse_config) Unknown field slave
ALSA lib pcm_dmix.c:961:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
INFO: Scheduling PortAudio Render Task...
INFO: PortAudio Render Task Running...

julia> 

[ssfrr]

@staticfloat, @shashi, @flpf, @maackle, @dpsanders

It would be super helpful if I could get the following info:

1. output of AudioIO.Pa_GetVersion()
2. output of versioninfo()
3. whether you see the warnings when running the latest AudioIO release (v0.1.1)
4. if you see the warnings, how often?
5. Do you see the "Input Overflow" or "Output Underflow" warning?
6. whether the audio is glitchy or smooth

The following should be sufficient test code (please run it on a fresh Julia REPL):

using AudioIO
play(SinOsc(220)*0.2);

Thanks all! I definitely want to track this down but I'm having a hard time reproducing it.

[flpf]

I can't reproduce this error because the play()-function didn't work anymore after I updated the AudioIO-package and julia a couple of weeks ago. I figured it has something to do with my personal alsa/portaudio setup in combination with the julia version I use so I haven't filed an issue.

[ssfrr]

OK, feel free to open an issue anyways if you'd like some help figuring things out. If you're running into an issue it's likely others will as well, so it's good to have these in a searchable location. Eventually I'll probably also add a FAQ, so having these as issues is nice for looking through to see what should be on it.

[staticfloat]

On latest AudioIO master:

julia> using AudioIO

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

julia> AudioIO.Pa_GetVersion()
1899

julia> play(SinOsc(220)*0.2);
INFO: Initializing PortAudio. Expect errors as we scan devices
INFO: Scheduling PortAudio Render Task...
INFO: PortAudio Render Task Running...

julia>

That is to say, no warnings. Running on the latest tagged version:

julia> using AudioIO

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

julia> AudioIO.Pa_GetVersion()
1899

julia> play(SinOsc(220)*0.2);
INFO: Initializing PortAudio. Expect errors as we scan devices
INFO: Scheduling PortAudio Render Task...
INFO: PortAudio Render Task Running...

WARNING: libportaudio: Input overflowed
julia> WARNING: libportaudio: Output underflowed
WARNING: libportaudio: Input overflowed
julia> WARNING: libportaudio: Input overflowed
WARNING: libportaudio: Input overflowed
WARNING: libportaudio: Input overflowed
WARNING: libportaudio: Input overflowed
WARNING: libportaudio: Input overflowed
WARNING: libportaudio: Input overflowed
WARNING: libportaudio: Input overflowed
WARNING: libportaudio: Input overflowed
...

That is to say, lots of warnings. Looks like we get a few Output underflowed, but mostly Input overflowed.

[sbromberger]

If it helps:

I'm also getting WARNING: libportaudio: Input overflowed on a play() of osc1 = SinOsc(440). The warnings persist even after stop().

julia> versioninfo()
Julia Version 0.4.0-dev+2529
Commit 322cf26 (2015-01-06 17:18 UTC)
Platform Info:
  System: Darwin (x86_64-apple-darwin14.0.0)
  CPU: Intel(R) Core(TM) i7-3820QM CPU @ 2.70GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

julia> AudioIO.Pa_GetVersion()
1899

Update: the latest master doesn't exhibit this problem and outputs sound correctly.

[flpf]

@ssfrr, @shashi

Hi, after solving #41 I still have the same error as described above. I just want to let you know that today I noticed that julia is constantly locked to a pulseaudio stream, which is the audio driver I use in my system, whereas other software only opens a stream when recording or playing-back audio. Another thing I've noticed over the last couple of days is that the error seems to be occuring when julias compiler kicks in:

julia> e^2
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
WARNING: libportaudio: Output underflowed
7ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
WARNING: libportaudio: Output underflowed
.38905609893065

julia> e^2
7.38905609893065

julia> e^2
7.38905609893065

The first call gives an instantanious error subsequent calls are fine.

I assume the error occurs when the portaudio stream is disconnected shortly from the pulseaudio stream while another process is running.

I'm not shure if this is 'locking'-behaviour is intentional of the AudioIO-package or characteristic to my audio setup.

Any ideas are appreciated...

[ssfrr]

The drop-outs while Julia is JIT compiling or garbage collecting are pretty much unavoidable at the moment. There is some work on Julia core to allow multithreading and incremental garbage collection which should help both those issues enormously. The GC is only really an issue now if it's deallocating a lot of memory at once, but the JIT compilation will cause dropouts compiling just about anything.

Keeping the audio stream open instead of closing it when there are no AudioNodes playing is a conscious decision to reduce overhead, latency, and clicks when you play a new node. This behavior is pretty common in audio software that does realtime audio synthesis, but I could see it might not be the right thing for the common case of just wanting to play some sounds once in a while. Maybe I should make it configurable.

Are you getting the dropouts when Julia isn't compiling anything?

[flpf]

Yes, the error message fills the REPL even when julia is idle. I understand the design decision and think this problem is basically my audio setup. I really like to help solve this problem but I think that it is not the most urgent issue at the moment. Meanwhile, because I use julia and AudioIO on a daily basis, I think a pragmatic step would be to turn off the error messages locally. Can I turn off the error-pipe without messing up the package?

[ssfrr]

If you checkout master the error messages are disabled by default. I should probably tag a release with that change, as there are also some others who get the error message without even hearing any dropouts, so it's just extra noise.

[flpf]

Ok. I just did that. The warning messages are gone but I still receive the alsa info:

using AudioIO

WARNING: deprecated syntax "{a=>b, ...}" at /home/fl/.julia/v0.4/AudioIO/src/portaudio.jl:40.
Use "Dict{Any,Any}(a=>b, ...)" instead.

WARNING: deprecated syntax "[a=>b, ...]" at /home/fl/.julia/v0.4/AudioIO/src/sndfile.jl:20.
Use "Dict(a=>b, ...)" instead.

julia> play(SinOsc(220))
INFO: Initializing PortAudio. Expect errors as we scan devices
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm_route.c:947:(find_matching_chmap) Found no matching channel map
ALSA lib pcm_route.c:947:(find_matching_chmap) Found no matching channel map
connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=No such file or directory)
attempt to connect to server failed
INFO: Scheduling PortAudio Render Task...
INFO: PortAudio Render Task Running...
AudioIOALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
.AudioNode{AudioIO.SinOscRenderer{T<:Union(AudioIO.AudioNode{T<:AudioIO.AudioRenderer},Float32)}}(trueALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
,ConditionALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
(Any[]),AudioIOALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
.SinOscRenderer{Float32}(22ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
0.0f0,2.4176657f0,Float32[0.0428228,0.011491,-0.0198521,-0.0511757,-0.082449,-0.113641,-0.144722,-0.175661,-0.206426,-0.23699  …  -0.319127,-0.348671,-0.377873,-0.406703,-0.435134,-0.463137,-0.490686,-0.517752,-0.544309,-0.570332]))
julia> stop(ans)
julia> ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred

Is there a way to get rid of those messages too?

[ssfrr]

The ALSA messages are trickier, because they're actually printed to STDOUT by the portaudio library itself. From what I can tell from the portaudio SVN history that behavior was removed circa 2010, but maybe whatever your distribution is using is older than that. If you install portaudio from source from the latest trunk it shouldn't print to STDOUT whenever there's an xrun.

[flpf]

Understood. I think I am on the latest portaudio release:

julia> AudioIO.Pa_GetVersion()
1899

From a portaudio software:

PortAudio version number = 1899
PortAudio version text = 'PortAudio V19-devel (built Jan 31 2014 21:19:35)'

Or is there a more recent version? As far as I see It, there is no easy way of solving this issue at the moment and it seems to be specific to my audio setup (gnome on arch linux i.e. pulseaudio calling alsa) . One thing I could try is to get rid of gnome, which explicitly needs pulseaudio, and see if that helps.

[flpf]

Removing gnome alongside portaudio did not help. Building PortAudio from source reduced the number of warnings but they are still present. I think for now I take the easy way and shell-out.

Should I close this issue for now?

[ssfrr]

Ah, it looks like that error isn't printed where I thought it was. In the PortAudio file pa_linux_alsa.c, in the PaAlsaStream_HandleXrun function, it calls alsa_snd_pcm_recover with the third argument 0. That argument controls whether or not that ALSA function prints out an error reason. It looks like that's still the case with the most recent commit, so I'll get in touch with the PortAudio devs to see if that's going to change any time soon.

If you want to rebuild PortAudio from source you can just change that third argument to 1 and it should suppress the warnings. Let's keep this issue open to remind me that there's still some things to do here:

• [ ] Pin a release with the new silent-by-default behavior
• [ ] Work out with the PortAudio devs what to do about the error message and add a FAQ

[flpf]

Ok. Thank you for looking into this. I'll change that argument and rebuild portaudio.

[flpf]

I was wondering if it would be possible to include something like Octaves 'sound()' or 'soundsc()'function in AudioiO. I just wrote a small script using AudioIO-functions to illustrate the idea. It seems to work without error messages.

I had some time to look through the code of the package and I think that I understood your idea a little bit better. For the node-concept a steadily open stream makes much more sense. But for simple playback of time-series or imported wave-files a function like:

using AudioIO
AudioIO.Pa_Initialize()
function soundd(sound::Vector,sampleRate::Real=48000)
    fac=div(length(sound),sampleRate);
    streamM=AudioIO.Pa_OpenDefaultStream(0,1,AudioIO.paFloat32,sampleRate,fac);
    AudioIO.Pa_StartStream(streamM);
    for i=1:fac
    AudioIO.Pa_WriteStream(streamM,convert(Array{Float32},sound[(i-1)*sampleRate+1:i*sampleRate]));
    end
    AudioIO.Pa_StopStream(streamM)
    AudioIO.Pa_CloseStream(streamM)
end 

could be of use. The snippet above is not generic and still has errors but I guess it captures the idea. Would this be something for AudioIO.jl or is it against the basic rationale of the package?

[ssfrr]

I just heard back from the main PortAudio dev and he supports enabling the silent flag. If none of the other core devs disagree then the change will probably happen. It'll be a while before it makes it into the distribution packages, but it's nice that things are looking good for an eventual upstream fix.