Add Sun/NetBSD hostapi

[alarixnia]

This hostapi has been available in the pkgsrc package for PortAudio for over a year (we build for Solaris and NetBSD). It was inspired by problems interfacing between PortAudio's OSS hostapi and NetBSD's OSS
compatibility layer that I couldn't fix without adding very ugly hacks to the OSS hostapi - in the end I decided to write a new, clean one for the native interface.

Tested building with the autotools and CMake build systems. Test and example programs work.

[Be-ing]

Thanks for opening this PR. Is sndio available on these systems? IIUC that is compatible with a wider variety of BSDs and also available on some Linux distros such as Gentoo. Would that be better to have upstream? I'm not familiar with how audio works on any of those systems; maybe it would be helpful to support both this and sndio? Someone started a sndio backend years ago but it was never finished. I don't know if it would be better to revive that old code or start over for sndio. Would you be interested in working on a sndio backend?

[alarixnia]

I'm not personally interested in sndio because we don't use it (NetBSD and Solaris have in-kernel mixers), but maybe the OpenBSD people would be.

[philburk]

Thanks for contributing. This looks very nice but it still needs a more detailed review.
I notice that pa_unix_oss.c has some "# ifdef NetBSD" conditionals.
I suppose people using PA_USE_OSS on NetBSD should migrate to PA_USE_SUN.
But we will probably need to keep the NetBSD conditionals in pa_unix_oss.c so we do not break people.

The PA_USE_SUN feels a bit odd. Oracle bought SUN in 2010 so SUN as a company does not really exist.
How many people are still using Solaris vs NetBSD? Maybe this should be PA_USE_OSS_SOLARIS or PA_USE_OSS_NETBSD. I don't know that market.

This all could be a little confusing. So we should have clear recommendations for what people should use in each case.

[Be-ing]

I agree, the naming is confusing. I was just looking into the history of the API this interacts with. IIUC this originaly came from SunOS or Solaris (which are not the same thing) then NetBSD reimplemented the API from scratch later?

[Be-ing]

What practical advantages are there to using this rather than the ALSA backend?

[alarixnia]

It's called "sun" in libao and "solaris" in OpenAL. I think it is called "SADA" internally to Solaris (although glancing the illumos source code this isn't really mentioned except in a few code comments, audio(7i) is what it's documented as). On NetBSD it's called audio(4). Another name that would make sense would be "audioio", after the header file.

It's also used on GNU HURD via the NetBSD rump kernel. The NetBSD implementation has been extended significantly over the years.

What practical advantages are there to using this rather than the ALSA backend?

Lower latency (and working latency tracking), working device selection, proper evaluation of hardware features, etc. Using alsalib on non-linux provides quite an unpleasant user experience and I would only use it as a last resort, otherwise I wouldn't have written this code. Everything is emulated. I'd rather use JACK, but the point is to have something with direct access to iterate devices that requires no configuration.

[Be-ing]

Another name that would make sense would be "audioio", after the header file.

I like this the most considering the other options. It is a very generic name, but it does communicate what is required for it.

[philburk]

Nice! Thanks for contributing.

[alarixnia]

Thanks for merging this.