RtAudio Update Tracker

Needed Updates & Possible New Features:

#	Description	Status
1	Check implementation of various stream options (RTAUDIO_HOG_DEVICE, ...) to verify proper implementation.	UC
2	Do API-specific implementations of stream time where possible.	UC
3	Better support for multichannel (>2) audio devices in Windows DirectSound API.	UC
4	Mixer support to set the input volume, output volume, and select the input source (e.g., "Mic" vs "Line In") via following new methods: `double getStreamOutputVolume()`: // returns value between 0.0 and 1.0 `void setStreamOutputVolume( double volume )`: // volume should be value between 0.0 and 1.0 `double getStreamInputVolume()`: // returns value between 0.0 and 1.0 `void setStreamInputVolume( double volume )`: // volume should be value between 0.0 and 1.0 `void getStreamInputSources( std::vector<std::string>& sources )`: // returns a vector of strings with source names `void setStreamInputSource( unsigned int index )`: // source index is value between 0 and sources.size()-1, as determined from function above	UC⁴
5	Robust support for full-duplex with different devices. Provide well-defined behavior if the devices get out of sync, with input taking precedence, so no incoming samples are lost (if possible).	UC
6	More sophisticated querying of device capabilities - for example, it'd be nice to figure out that a device supports either 4 channels of 16-bit or 2 channels of 24-bit audio.	UC
7	A faster device querying capability in DirectSound API - the current approach can take an extremely long time, especially for devices with many channels (like an RME Fireface 800).	UC
8	A way to specify a desired device name, instead of a device index, when opening a stream?	UC

Status Codes:

UC Under Consideration

API? Approved but need to determine API change

Recently Added Features:

#	Description	Solution	Version
1	Stream time support - ability to query the stream and find out the exact time since the stream was started, according to that device's clock. For APIs where this is not supported, this is estimated based on a count of the bytes that have been sent and the known latency.	¹New `getStreamTime()` function (DM)	4.0
2	Ability to determine whether stream is currently running.	New `bool isStreamRunning()` function (DM)	4.0
3	NetBSD support added to Linux OSS API.	__NetBSD__ must be defined (Emmanuel Dreyfus)	4.0
4	Added function to return available compiled APIs	New `getCompiledApi()` function (GS)	4.0
5	Changed `isDefault` member of RtAudioDeviceInfo structure to `isDefaultOutput` and `isDefaultInput` to be able to distinguish between default input and output devices.	Modified `RtAudioDeviceInfo` structure (GS)	4.0
6	Added function to return current API for RtAudio instance	New `getCurrentApi()` function (GS)	4.0
7	Added function to return current stream device(s) index	New `getStreamDevice()` function (GS)	4.0
8	Dummy version that compiles without API compiler flag but does nothing	New `RtApiDummy` class (GS)	4.0
9	Ability to query device latency.	²New `getStreamLatency()` function (GS)	4.0
10	Choice of opening a device in exclusive or non-exclusive mode. If opening in non-exclusive mode, try to use the device as-is without changing its sample rate, etc - this is good when users want to use two audio devices at once.	³New RtAudio::StreamOptions structure and parameters	4.0
11	Previous CoreAudio support included only a single stream with multiple channels or multiple one-channel streams.	Added support for arbitrary stream channel configurations (GS)	4.0.5
12	Added function to return actual sample rate used by a stream because sometimes it varies slightly from the specified one.	New `getStreamSampleRate()` function (Theo Veenker)	4.0.5
13	Added way to specify realtime scheduling for unices.	New StreamOptions flag "RTAUDIO_SCHEDULE_REALTIME" and attribute "priority" to StreamOptions (Theo Veenker)	4.0.5

Details:

¹Currently implemented by incrementing a counter every time the tickStream() or callback function is called. If the gettimeofday() function is available (right now it is enabled for all Unix-like systems but not Windows), it also records the time of each tickStream() call. Then, when you call getStreamTime(), it adds the elapsed time since the last tickStream also. This makes the playback counter pretty smooth, but accurate. The intent is that now we could implement something more accurate on platforms that support it - but this is a reasonable baseline. One thing to watch out for: asking OSS for the stream time is problematic; on some devices the counter is only 16-bit and wraps around frequently, and on some devices it will sometimes return bogus values.

²This function could not be implemented for all APIs. If the function returns a value of zero, it should be assumed to be invalid.

³This implementation does not attempt to leave a device as-is. However, the flag RTAUDIO_HOG_DEVICE is provided to attempt to grab exclusive use of a device.

⁴I actually coded this up for OS-X Core Audio. However, I found it bloated the code and presented a number of interface problems that did more harm than good. Thus, it is currently not being considered further (GS).

UC	Under Consideration
API?	Approved but need to determine API change