Audio Underflow on loading "examples/sharedsystem/audiosetup.xtm"

[RandomOutput]

Following the instructions in the pattern language guide, I attempt to run (sys:load "examples/sharedsystem/audiosetup.xtm"). After loading several modules, I get the repeated terminal message, Audio underflow: are you pushing extempore too hard?

ARCH           : x86_64-pc-windows-msvc-elf
LLVM           : 3.8.0 MCJIT
Output Device  : Speakers / Headphones (Realtek 
Input Device   : 
SampleRate     : 44100
Channels Out   : 2
Channels In    : 0
Frames         : 1024
Latency        : 0.0928798 sec
Primary        : thread 0

INFO: starting utility process...
INFO: server: accepted new connection to utility process
INFO: client: connected to server utility process at localhost:7098
INFO: starting primary process...
INFO: server: accepted new connection to primary process
INFO: client: connected to server primary process at localhost:7099
Loading xtmbase library... done in 1.746399 seconds
INFO: server: accepted new connection to primary process
Loading xtmrational library... done in 1.159764 seconds
Loading xtmaudiobuffer library... done in 1.072886 seconds
Loading xtmaudio_dsp library... done in 2.523337 seconds
Loading xtminstruments library... done in 6.618279 seconds
Loading xtmsndfile library... done in 1.575314 seconds
Loading xtminstruments_ext library... done in 0.257142 seconds
sys:load notification instruments_ext already loaded
Loading xtmmath library... done in 2.925909 seconds
Loading xtmfft library... done in 0.652922 seconds
Loading xtmaudio_dsp_ext library... done in 0.171200 seconds
sys:load notification audio_dsp_ext already loaded
SetValue:  syn1 >>> [float,float,i64,i64,float*]*
New instrument bound as syn1 in both scheme and xtlang
SetValue:  syn2 >>> [float,float,i64,i64,float*]*
New instrument bound as syn2 in both scheme and xtlang
SetValue:  syn3 >>> [float,float,i64,i64,float*]*
New instrument bound as syn3 in both scheme and xtlang
SetValue:  kit >>> [float,float,i64,i64,float*]*
New instrument bound as kit in both scheme and xtlang
SetValue:  samp1 >>> [float,float,i64,i64,float*]*
New instrument bound as samp1 in both scheme and xtlang
errors:  Not a valid SNDFILE* pointer.
errors:  Not a valid SNDFILE* pointer.
INFO: Loaded 30 files into bank 0
errors:  Not a valid SNDFILE* pointer.
errors:  Not a valid SNDFILE* pointer.
errors:  Not a valid SNDFILE* pointer.
INFO: Loaded 30 files into bank 1
errors:  Not a valid SNDFILE* pointer.
errors:  Not a valid SNDFILE* pointer.
errors:  Not a valid SNDFILE* pointer.
errors:  Not a valid SNDFILE* pointer.
INFO: Loaded 30 files into bank 2
INFO: Loaded 31 files into bank 3
INFO: Loaded 28 files into bank 4
Compiled:  dsp1 >>> [float,float,i64,i64,float*]*
Compiled:  dsp2 >>> [float,float,i64,i64,float*]*
Compiled:  dsp3 >>> [float,float,i64,i64,float*]*
Compiled:  dsp4 >>> [float,float,i64,i64,float*]*
Compiled:  dsp5 >>> [float,float,i64,i64,float*]*
Compiled:  dspmt >>> [float,float*,i64,i64,float*]*
IR:(3.1 seconds) Partitions(size:4096 num:33)
IR:(3.1 seconds) Partitions(size:4096 num:33)
zerolatency: #f
Starting RT Audio process with SIG CNT: 0
Starting RT Audio process with SIG CNT: 0
Starting RT Audio process with SIG CNT: 0
Starting RT Audio process with SIG CNT: 0
Starting RT Audio process with SIG CNT: 0
Compiled:  active_notes >>> [i32,i8*]*
Compiled:  dsp_load >>> [void]*
Audio underflow: are you pushing extempore too hard?
Compiled:  main_reverb >>> [void,i64,float]*
Compiled:  main_gain >>> [float,float]*
pattern starting DSP_LOAD
sharedsystem audio setup complete
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?n:0] 5:[11% n/a]
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?n:0] 5:[14% n/a]
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?n:0] 5:[16% n/a]
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?n:0] 5:[18% n/a]
Audio underflow: are you pushing extempore too hard?
Audio underflow: are you pushing extempore too hard?

[benswift]

Hey @RandomOutput this came up with some students in my class the other day (who are using Extempore) and I wrote up some stuff which might help.

The --frames one is the first thing to try, anyway.

I'll make this stuff clearer on the main docs website ASAP, but I thought I'd drop that link in there for now to get you started.

[RandomOutput]

Thanks @benswift I’ll give these a try and see if I can sort out the issue.

[avdrd]

I'm having the same problem on Windows 10 with Extempore. SuperCollider, Csound even Kronos work fine on the same machine. CPU load is pretty high with Extempore, unlike with any of the others. I can run hundreds of ugens in SuperCollider on this box, with CPU load still under 2%.

TLDR: the problem in Extempore manifests itself only with the more complex pattern based examples like

(sys:load "examples/sharedsystem/audiosetup.xtm")

(:> ascending-scale 4 0 (play syn1 @1 80 dur) (scale 4 8))

That sys:load also prints a number of errors about invalid SNDFILE* pointers. The VS2019 and VS2016 packages behave differently in terms of output, despite showing similar errors. The VS2019 package has high cpu load and dropout but makes some sound with patterns. The VS2016 package prints some additional runtime errors and makes no sound with patterns. Both are fine with a simpler non-pattern example.

Here's what happens with VS2019 packaged v0.8.9:

SetValue:  samp1 >>> [float,float,i64,i64,float*]*
New instrument bound as samp1 in both scheme and xtlang
errors:  Not a valid SNDFILE* pointer.
errors:  Not a valid SNDFILE* pointer.
INFO: Loaded 30 files into bank 0
errors:  Not a valid SNDFILE* pointer.
errors:  Not a valid SNDFILE* pointer.
errors:  Not a valid SNDFILE* pointer.
INFO: Loaded 30 files into bank 1
errors:  Not a valid SNDFILE* pointer.
errors:  Not a valid SNDFILE* pointer.
errors:  Not a valid SNDFILE* pointer.
errors:  Not a valid SNDFILE* pointer.
INFO: Loaded 30 files into bank 2
INFO: Loaded 31 files into bank 3
INFO: Loaded 28 files into bank 4
Compiled:  dsp1 >>> [float,float,i64,i64,float*]*
Compiled:  dsp2 >>> [float,float,i64,i64,float*]*
Compiled:  dsp3 >>> [float,float,i64,i64,float*]*
Compiled:  dsp4 >>> [float,float,i64,i64,float*]*
Compiled:  dsp5 >>> [float,float,i64,i64,float*]*
Compiled:  dspmt >>> [float,float*,i64,i64,float*]*
IR:(3.7 seconds) Partitions(size:32768 num:5)
IR:(3.7 seconds) Partitions(size:32768 num:5)
zerolatency: #f
Starting RT Audio process with SIG CNT: 0
Starting RT Audio process with SIG CNT: 0
Starting RT Audio process with SIG CNT: 0
Starting RT Audio process with SIG CNT: 0
Starting RT Audio process with SIG CNT: 0
Compiled:  active_notes >>> [i32,i8*]*
Compiled:  dsp_load >>> [void]*
Compiled:  main_reverb >>> [void,i64,float]*
Compiled:  main_gain >>> [float,float]*
pattern starting DSP_LOAD
sharedsystem audio setup complete
pattern starting ascending-scale 3:[13% n:0] 4:[12% n:0] 5:[16% n/a]
DSP load 1:[16% n:0] 2:[14% n:0] 3:[13% n:0] 4:[13% n:0] 5:[14% n/a]

And then the DSP load is high and the sound choppy. Changing drivers, increasing buffer size all the way up to 16384, made no difference. Extempore doesn't support ASIO as shipped, by the way.

On the other hand, a simpler (library-wise) example like

;; load the instruments file
(sys:load "libs/core/instruments.xtm")

;; define a synth using the provided component fmsynth
(make-instrument synth fmsynth)

;; add the instrument to the DSP output sink closure
(bind-func dsp:DSP
  (lambda (in time chan dat)
    (synth in time chan dat)))
(dsp:set! dsp)

;; play a note on our synth

(play-note (now) synth (random 60 80) 80 (* 1.0 *second*))

works without any audio chopping and cpu load is non-existent at the default 1024 buffer and even default MME drivers.

So, there seems to be some bug in the library as it's compiled and shipped on Windows, perhaps related to those invalid SNDFILE* pointers.

The above was with the VS2019 binaries v0.8.9.

Interestingly, the VS2016 v0.8.9 package, which also runs the simple non-pattern example without a hitch, also shows same errors when loading the patter libs, however, CPU load doesn't shoot up!

New instrument bound as samp1 in both scheme and xtlang
errors:  Not a valid SNDFILE* pointer.
errors:  Not a valid SNDFILE* pointer.
INFO: Loaded 30 files into bank 0
errors:  Not a valid SNDFILE* pointer.
errors:  Not a valid SNDFILE* pointer.
errors:  Not a valid SNDFILE* pointer.
INFO: Loaded 30 files into bank 1
errors:  Not a valid SNDFILE* pointer.
errors:  Not a valid SNDFILE* pointer.
errors:  Not a valid SNDFILE* pointer.
errors:  Not a valid SNDFILE* pointer.
INFO: Loaded 30 files into bank 2
INFO: Loaded 31 files into bank 3
INFO: Loaded 28 files into bank 4
Compiled:  dsp1 >>> [float,float,i64,i64,float*]*
Compiled:  dsp2 >>> [float,float,i64,i64,float*]*
Compiled:  dsp3 >>> [float,float,i64,i64,float*]*
Compiled:  dsp4 >>> [float,float,i64,i64,float*]*
Compiled:  dsp5 >>> [float,float,i64,i64,float*]*
Compiled:  dspmt >>> [float,float*,i64,i64,float*]*
IR:(3.1 seconds) Partitions(size:4096 num:33)
IR:(3.1 seconds) Partitions(size:4096 num:33)
zerolatency: #f
You can only set the DSP callback once, but you
can re-define that function as often as you like
Starting RT Audio process with SIG CNT: 0
Starting RT Audio process with SIG CNT: 0
Starting RT Audio process with SIG CNT: 0
Starting RT Audio process with SIG CNT: 0
Starting RT Audio process with SIG CNT: 0
Compiled:  active_notes >>> [i32,i8*]*
Compiled:  dsp_load >>> [void]*
Compiled:  main_reverb >>> [void,i64,float]*
Compiled:  main_gain >>> [float,float]*
pattern starting DSP_LOAD
sharedsystem audio setup complete
DSP load 1:[ 0% n:0] 2:[ 0% n:0] 3:[ 0% n:0] 4:[ 0% n:0] 5:[ 0% n/a]

But that was false hope. The VS2016 package doesn't make any sound at all with the pattern:

(sys:load "examples/sharedsystem/audiosetup.xtm")
(:> ascending-scale 4 0 (play syn1 @1 80 dur) (scale 4 8))

Just prints something like

pattern starting ascending-scale
stack-catch: ()
stack-catch: ()
stack-catch: ()
stack-catch: ()
eval: unbound variable: Audio
Trace:
Attempting to return a string from non-symbol obj #fn:0] 5:[ 0% n/a]
Trace: callback-adapter
DSP load 1:[ 0% n:0] 2:[ 0% n:0] 3:[ 0% n:0] 4:[ 0% n:0] 5:[ 0% n/a]
!Still locked in 0 cnt(0:0)
!Still locked in 1 cnt(0:0)
!Still locked in 2 cnt(0:0)
!Still locked in 4 cnt(0:0)
DSP load 1:[ 0% n:0] 2:[ 0% n:0] 3:[ 0% n:0] 4:[ 0% n:0] 5:[ 0% n/a]]

So at this point I'm guessing the issue is perhaps related to the libraries build, perhaps relative to the ASSETS. I'll try to compile from source a bit later with the latest VS2019 -- they patch it quite a lot. LLVM also had some bugs recently, affecting Faust.

---

I've done my own build and it's just a broken. So you've definitely got a bug on Windows.

I'm a bit too tired to edit the above now, but my description above about VS2019 vs VS2016 was a red herring. The actual cause of those difference in behavior was dependent only on whether I had loaded the simpler example first or not.

[digego]

It looks like you're running the "sharedsystem", which is a good idea and I recommend it, however, it is a CPU hog - convolution reverb, "analogue modeling" etc., out the box. Just keep in mind that the "sharedsystem" isn't designed for low end hardware. Now, with that said, Extempore is very sensitive to audio drivers (and it reports its xruns). Good drivers on windows work great, bad drivers don't. I know that's not particularly helpful, I guess I'm just recommending that you play around a little as I can assure you that windows does work fine with the right setup - although this can sometimes be a pain to find. One thing to keep in mind on windows is cpu frequency scaling, which causes all sorts of headaches on windows in my experience - particularly on laptops. Do your best to turn off frequency scaling when running Extempore and you'll have a much better time of it on windows.

…

On Sun, Dec 26, 2021 at 4:39 AM avdrd ***@***.***> wrote: Having the same problem on Windows with extempore. SuperCollider, Csound even Kronos work fine on the same machine. CPU load is pretty high with extempore, unlike with any of the above Audio underflow: are you pushing extempore too hard? Audio underflow: are you pushing extempore too hard?n:0] 5:[17% n/a] Since Kronos is also clang-based, but has little CPU load, that alone can't be the issue. — Reply to this email directly, view it on GitHub <#402 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEHPKOI3R6CAWCU2QQPBWDUSX6WNANCNFSM44OBIASQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[avdrd]

It's a desktop with fixed CPU frequency (mobo option). I've been using it for years for music making stuff because it avoids such issues. I mean, AVX512... no thanks, Intel.