|
How to perform a recording session |
  
|
|
How to perform a recording session |
|
The architecture of the control is based upon the graph below:
Sound cards supporting DirectSound and/or ASIO drivers can be used in order to start recording sessions. Both kind of drivers will obtain a sound stream from input channels available on the installed sound card(s) and will send it to the recorder control in form of a PCM stream. At this point the recorder control will send the stream to an encoder that will save the stream encoded in one of the available formats (WAV, MP3, WMA, etc.) to a destination file or memory buffer. If needed, before being sent to the encoder, the PCM stream could be still processed by one or more custom DSPs in order to perform analysis and/or special effects on the stream itself.
Before starting a recording session, the component needs to be initialised: for this purpose it's mandatory a call to the InitRecordingSystem method; the best place to call this method is usually the container form initialisation function: for example, when using Visual Basic 6, it will be the Form_Load subroutine.
When you need recording from an input device, you must know how many input devices are installed inside the system, their supported drivers/protocols and how many channels are available inside each input device: starting from version 4, Active Sound Recorder can support both DirectSound and ASIO drivers. By default, only DirectSound input devices will be listed. In order to enable the usage of ASIO input devices also, refer to the How to manage ASIO drivers tutorial.
The number and friendly descriptions of available input devices (intended as sound cards) can be obtained through a prior call to the GetInputDevicesCount and GetInputDeviceDesc methods.
The number and friendly descriptions of available input channels (Microphone, Line-In, etc.), relative to a certain input device, can be obtained through a prior call to the GetInputDeviceChannelsCount and GetInputDeviceChannelDesc methods.
When dealing with DirectSound devices, the system default input channel for a certain input device can be changed at system level (so it will be reflected inside the "Sounds" applet of the Windows Control Panel) through a call to the SetInputDeviceChannelDefault method. The volume of the input channel can be changed, again at at system level, through the SetInputDeviceChannelVolume method.
When a new USB device is plugged-in or unplugged, the container application will receive a DeviceChange event: after receiving this event, if you need to remain in sync with available sound cards, you will have to reset the multimedia engine through the ResetEngine method: after this resetting procedure (whose completion could require some second) it will be again possible enumerating available input devices through the GetInputDevicesCount and GetInputDeviceDesc methods. At this point you will have to re-initialize the control through the ResetControl method.
Once decided the control's input source, it's time to decide where and how the control will store recorded sound data; the first thing to decide is the output format of the recorded sound: for this purpose you need to set the EncodeFormats.ForRecording property to one of the available encoding formats.
Each encoding format set into the EncodeFormats.ForRecording property have its own settings which can be controlled through sub-properties of the EncodeFormats property: for example, if the chosen encoding format should be ENCODING_FORMAT_WAV you would have to modify settings of the EncodeFormats.WAV property, if chosen encoding format should be ENCODING_FORMAT_MP3 you would have to modify settings of the EncodeFormats.MP3 property and so on for the remaining accepted encoding formats.
Before starting a recording session, you need to check if the Status property is set to RECORD_STATUS_READY: if the property value should be RECORD_STATUS_NOT_READY, this would mean that initialization of the control and negotiation with underlying drivers is still not completed.
In case there should be the need to resample incoming sound data, for example for reducing the final recording size, it could be convenient checking the EncodeFormats.ResampleMode property and choose which of the available resample modes would best fit your needs.
At this point we can start the recording session calling the StartFromDirectSoundDevice method which needs to know the output file location: if an absolute pathname is specified, it can be a file on the system hard disk or, if the pathname is left empty, a memory file that could be used at a later time, for example in order to perform a custom encrypting before saving it to a file on disk: it's highly suggested avoiding the use of memory based recording sessions for a duration longer than 5 minutes because they could require a huge amount of memory: for a longer duration the output on files should be preferred.
During the recording session, the container application can be notified about the current duration through the RecordingDuration event and about the current disk or memory occupation through the RecordingSize event: note that, for reducing the amount of bytes requested for storing sound data, the control gives the possibility to discard silent data, i.e. portions of sounds that cannot be heard: see section How the Sound Activation System works for further details about this feature.
The current recording session can be stopped at any time through the Stop method.
The current recording session can be paused through the Pause method and resumed through the Resume method.
After stopping the current recording session, you have the possibility to start a new one without discarding the existing one: for this purpose you need to define how the new recording session will behave through a call to the SetRecordingMode method: this will allow appending the new recording session to the existing one or inserting/mixing/overwriting the new recording session to a given position of the existing one: see the SetInsertPos, SetMixingPos and SetOverwritePos methods for defining where the new recording session will be inserted/mixed/overwritten.
It's important to note that, after stopping a restarted recording session, the total recorded sound will not be immediately available because there will be the need to finalize and join the new recording session with the previous one: the container application will be informed about the start/end of the automatic finalization process through the RecordingFinalizationStarted and RecordingFinalizationDone events.
Once a recording session has been stopped, the control can manage recorded sound data, stored on a disk file or inside a memory buffer, through the following methods:
Note that playback capabilities are very limited: if you need more sophisticated playback features consider using this control in conjunction with our Active DJ Studio ActiveX control.
The recorded sound can be edited through one of the following methods:
Note that editing capabilities are quite limited: if you need more sophisticated editing features consider using this control in conjunction with our Active Sound Editor ActiveX control.
The recorded sound can be exported to a disk file or inside a memory buffer using the RecordedSound.RequestExportToFile method: see the How to export a recorded sound section for further details
The recorded sound can be also uploaded to a FTP server through the RecordedSound.RequestUploadToFTP method (the upload session can be cancelled through the RecordedSound.CancelUploadToFTP method) and can be also copied into the system clipboard in CF_WAVE format through the RecordedSound.CopyRangeToClipboard method.
As already stated before, if the strOutputPath parameter of the StartFromDirectSoundDevice method has been left blank, recorded sound data will be stored inside a memory buffer; the operation that can be performed on this memory buffer are the following:
While performing a recording session whose output will be stored inside a file on the hard disk, it could be useful having the possibility to save the recording session in more than one file without any interruption of the audio flow: for this purpose you can use the SwitchOutputFile or the SwitchOutputFileEx methods: the call to one of these method generates a RecordingOutputFileSwitch event.
After switching the output file one or more times, you can verify how many times the output file was switched through the SwitchedOutputFileGetCount method and, for each single output file, you can obtain the absolute pathname through the SwitchedOutputFileGetPathname method, the size in bytes through the SwitchedOutputFileGetSize method and its duration through the SwitchedOutputFileGetDuration method.
In case you should need to split the recording session in separate files containing the left and right channels respectively, you could use the StartSplitFromDirectSoundDevice method. In this case the recording session wouldn't be kept inside the RecordedSound object so the only accepted recording mode, set through the SetRecordingMode method, is REC_MODE_NEW.
During a recording session it's sometime useful having the possibility to add one or more position markers: a position marker is like a bookmark, and it is used to mark a location in a document. This is useful if you need to return to that location quickly or frequently without the need to manually search for a specific position inside a long recording session.
You can add/remove position markers using the PositionMarkerAdd and PositionMarkerRemove methods and you can retrieve the current number of available position markers through the PositionMarkerCountGetmethod. Each position marker is identified by a "unique identifier" which can be retrieved through the PositionMarkerUniqueIdGet method.
The position in milliseconds of each marker can be obtained or moved through the PositionMarkerPosGet and PositionMarkerPosSet methods and its friendly descriptor can be obtained through the PositionMarkerDescGet method..
