HRECORD BASS_RecordStart( DWORD freq, DWORD chans, DWORD flags, RECORDPROC *proc void *user );
|freq||The sample rate to record at.|
|chans||The number of channels... 1 = mono, 2 = stereo, etc.|
|flags||A combination of these flags.|
|proc||The user defined function to receive the recorded sample data... can be NULL if you do not wish to use a callback.|
|user||User instance data to pass to the callback function.|
|BASS_ERROR_INIT||BASS_RecordInit has not been successfully called.|
|BASS_ERROR_BUSY||The device is busy. An existing recording may need to be stopped before starting another one.|
|BASS_ERROR_NOTAVAIL||The recording device is not available. Another application may already be recording with it, or it could be a half-duplex device that is currently being used for playback.|
|BASS_ERROR_FORMAT||The requested format is not supported. If using the BASS_SAMPLE_FLOAT flag, it could be that floating-point recording is not supported.|
|BASS_ERROR_MEM||There is insufficient memory.|
|BASS_ERROR_UNKNOWN||Some other mystery problem!|
The sample data will generally arrive from the recording device in blocks rather than in a continuous stream, so when specifying a very short period between callbacks, some calls may be skipped due to there being no new data available since the last call.
When not using a callback (proc = NULL), the recorded data is instead retrieved via BASS_ChannelGetData. To keep latency at a minimum, the amount of data in the recording buffer should be monitored (also done via BASS_ChannelGetData, with the BASS_DATA_AVAILABLE flag) to check that there is not too much data; freshly recorded data will only be retrieved after the older data in the buffer is.
On OSX and iOS, the device is instructed (when possible) to deliver data at the period set in the HIWORD of flags, even when a callback function is not used. On other platforms, it is up the the system when data arrives from the device.
HRECORD record=BASS_RecordStart(44100, 2, 0, MyRecordProc, 0);