switch to cffi out-of-line ABI mode

[tgarc]

switch to out of line mode to improve sounddevice module import time.

this adds a separate sounddevice_build.py file that becomes part of
the setup.py build process and is only run once at install time rather
than everytime the module is imported

[mgeier]

Looks good to me. I'm on holidays for the next 2.5 weeks, I'll try it afterwards. Did you also try this on Windows?

[tgarc]

I will test on windows.

interesting side-note: making the same change for the soundfile library seems to have no impact on its import time

[tgarc]

with windows ran the same command:

$ (for i in {1..20}; do { time python -c 'import sounddevice' ; } 2>&1 | grep -oE '0\.[0-9]+'; done) | awk '{total += $1} END {print total}'

Linux:

A couple runs with sounddevice-0.3.8 gave 416ms, and 424ms
A couple of runs with out-of-line build gave 227ms and 247ms

Windows:
A couple runs with sounddevice-0.3.8 gave 371ms and 372ms
A couple of runs with out-of-line build gave 267ms and 267ms

[mgeier]

Sorry for the delay, now I'm back ...

I've tried it on macOS, but it produces an error:

>>> import sounddevice
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/.../sounddevice.py", line 2646, in <module>
    _ignore_stderr()
  File "/.../sounddevice.py", line 2638, in _ignore_stderr
    stdio.stderr = devnull
ffi.error: symbol 'stderr' not found in library '<None>': dlsym(RTLD_DEFAULT, stderr): symbol not found

It seems that instead of a KeyError we get an ffi.error.
I'm not sure if that's a bug in CFFI, but if I change KeyError to _ffi.error, it works!

[mgeier]

interesting side-note: making the same change for the soundfile library seems to have no impact on its import time

That's indeed interesting.
If I've counted correctly, the soundfile library has about 120 lines of C code to parse, while sounddevice has more than 300.
Is that the reason or is there something else going on?

[tgarc]

Seems unlikely that it's the difference in length..but your guess is as good as mine.

…

On Oct 11, 2017 4:45 AM, "Matthias Geier" ***@***.***> wrote: interesting side-note: making the same change for the soundfile library seems to have no impact on its import time That's indeed interesting. If I've counted correctly, the soundfile library has about 120 lines of C code to parse, while sounddevice has more than 300. Is that the reason or is there something else going on? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#102 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAaVHLxHqoW0JM-4nsErpCf9rPYGUnZ_ks5srI4vgaJpZM4PefmC> .

[mgeier]

@tgarc Do you want to add the fix for macOS or should I do that?

Apart from that, I think this is ready to merge.

[tgarc]

I can. But do you think both KeyErrors need to be changed?

…

On Oct 14, 2017 10:24 AM, "Matthias Geier" ***@***.***> wrote: @tgarc <https://github.com/tgarc> Do you want to add the fix for macOS or should I do that? Apart from that, I think this is ready to merge. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#102 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAaVHIrY0VdPCSfe5w05HMrTvENU7Rjlks5ssNI9gaJpZM4PefmC> .

[mgeier]

Thanks! Yes, I think both should be changed, since theoretically there might be neither stderr nor __stderrp available.

[tgarc]

done!

[tgarc]

okay I lied, I do see a modest improvement applying this change to the soundfile library as well. I think I just didn't see it on the machine I originally tested on because of other latency issues

[mgeier]

Thanks @tgarc!
I've added another twist in #103, what do you think about it?

[tgarc]

thanks for merging this! The same changes has now been merged with PySoundFile as well. This dropped my command line application run time (which imports sounddevice and soundfile) down from 130ms to about 50ms. This is a far cry from the <10ms launch times of e.g. aplay (alsa utility for playing audio) but is tolerable for my purposes.

Also FYI, if you're ever using entry_points with setup.py there's a huge runtime delay added unless the module is installed as a wheel (issue report here). Just another fun fact about setuptools.