Here are my opinions on implementation.
My current "recording" server has following features I like (doesn't mean
such API should have all these):
- Communication over TCP socket
- One lazy client (who is not reading it's data) doesn't affect others
- Sampleformat is normalized [-1..1] 32-bit float
- Network byteorder is used (big endian)
- Cross-platform (ie. OSS, ALSA and DirectX versions running on Linux,
*BSD, Solaris, QNX and Windows)
In fact it's two to three layer deep and more complex, but it works well in
non-heterogenous distributed processing environment and avoids wasting
bandwidth. Negative side is that recording latency isn't very low (few
hundred ms) :( ...
> - read(int channel_id, ...)
I think there should be one channel streaming/block IO and also interleaved
multichannel streaming/block IO.
> - negotiating the used audio format
I think we should work using normalized 32-bit IEEE FP. HAL should select
the best resolution automatically and possibly do some dither/noise
shaping/interpolation.
> - we could force all channels to be mono, but it might
> be useful to support interleaved streams
Definitely.
MY biggest problem is to keep cross-platform compatiblity. OSS runs on
multiple platforms. ALSA's biggest problem is that it currently runs only on
Linux and QNX. Not to even mention about f*cking Microsoft APIs.
Things that should be tought:
- Different OS platforms
- Different hardware platforms (big/little endian, 32/64-bit)
PLEASE, do not create yet-another Linux-x86 -only API... :|
- Jussi Laako
--
PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B 39DD A4DE 63EB C216 1E4B
Available at PGP keyservers
