This is a way to play and record directly using files in WAV format rather than having to copy the data between the file and the Prosody channel.
Note: the library which provides this API is equivalent to the Prosody high level WAV FILE API library except that instead of using the C standard library, stdio, it uses the bfile library to access files. On other systems, there is no particular need to use either in preference to the other.
If files for replay and record have the appropriate standard WAV file headers as explained in Prosody application note: WAV files then sm_replay_wav_bf_start(), sm_replay_wav_bf_close(), sm_record_wav_bf_start(), sm_record_wav_bf_close() and sm_record_wav_bf_trim_close() may be used to set up replay/record control blocks and manipulate these files (e.g. parse and write these headers).
These are used in conjunction with the Prosody high level BFILE play/record API .
The declarations for this library are in highapi/smbfwavlib.h
and applications using this library must be linked with the appropriate library - see Linking an application with the TiNG library
From time to time new features are added to this API. This may require new fields to be added to structures. A mechanism is available to ensure that this does not cause any problems for code developed prior to the addition. This is achieved by defining all new fields such that the value zero selects backward compatible behaviour. To take advantage of this, structures should be cleared before use. For example,
SM_CHANNEL_ALLOC_PLACED_PARMS ap; memset(&ap, 0, sizeof(ap)); ap.type = kSMChannelTypeFullDuplex; ... etc
This ensures that if a new field is ever added to this structure the new field is not left uninitialised.
The list of error codes that a function can return is only a list of typical errors. If a function is described as returning a standard error then it can return any such error. Also, when the description of a function says that it can return a particular error code (for example, ERR_SM_FIRMWARE_NOT_RUNNING), this does not mean that the function guarantees to detect this error condition in all circumstances. It merely means that if it does detect this error condition, then this is the code it will return.
There are situations where a successful call to a function causes an error condition to occur on a Prosody module, such as a request that requires a firmware module which has not been loaded. In these cases, the error condition is reported through a subsequent function call. This is usually a status function that is associated with the object which has caused the error. Some error conditions are more general. For example, a failure in communication with a Prosody module can be reported though any function call which refers to objects on that module.
This API is part of Prosody.