When compiling with Visual Studio (#49), prevents this error:
```
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\um\commdlg.h(929): error C2373: 'IPrintDialogCallbackVtbl': redefinition; different type modifiers
1> C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\um\commdlg.h(929): note: see declaration of 'IPrintDialogCallbackVtbl'
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\um\commdlg.h(961): error C2373: 'IPrintDialogServicesVtbl': redefinition; different type modifiers
1> C:\Program Files (x86)\Windows Kits\10\Include\10.0.10586.0\um\commdlg.h(961): note: see declaration of 'IPrintDialogServicesVtbl'
```
Previously, the `atomics.h` header relied solely on the presence of
the C11 specific header `stdatomic.h`. Now, when compiled in C++,
we use the `std::atomic` type family provided by the STL in C++11.
The main ALSA poll now includes another file descriptor which we
write to when cleaning up, to ensure that the poll terminates
when soundio_outstream_destroy is invoked.
closes#36
* Don't suppress sysdefault.
* If default and sysdefault are missing, use the first device as
the default device.
* In sio_record example, don't segfault when device not found or
probe error.
* Workaround for Raspberry Pi driver that incorrectly reports
itself as Output when it is actually Input.
See #44.
List<T> is now a really ugly macro.
Added a workaround for jack.h not putting `void` in function
prototypes for functions that take no arguments. I made upstream
pull requests to jack1 and jack2 but I don't have high hopes
about them getting merged.
I removed the lock-free atomic asserts. clang reports
non-lock-free atomics when in fact it does have lock-free
atomics. I inspected the generated code for gcc and clang
for fetch_add, load, and store, on x86_64 and armhf, and
it's all lock free.
Closes#45.
Previously, calling soundio_outstream_pause or soundio_instream_pause
during the write_callback or read_callback would cause a deadlock. Now,
attempting to pause always results in SoundIoErrorBackendIncompatible.
Closes#39
If the write_callback came upon an error during the prepare
phase, and never wrote any frames to the hardware buffer,
and another thread tried to soundio_outstream_destroy, this
would cause a deadlock.
This is now fixed.
