Namespace: Un4seen.BassWasapi
Assembly: Bass.Net (in Bass.Net.dll) Version: 2.4.17.5
[DllImportAttribute("basswasapi")] public static int BASS_WASAPI_GetData( IntPtr buffer, int length )
Parameters
- buffer
- Type: SystemIntPtr
Location to write the data to.Use "Marshal.AllocCoTaskMem" to allocate a memory buffer, use "Marshal.Copy" to copy the buffer data from unmanaged BASS to your managed code and use "Marshal.FreeCoTaskMem" to free the memory buffer when not needed anymore.
Or make use of a "GCHandle" to receive data to a pinned managed object.
- length
- Type: SystemInt32
Number of bytes wanted, and/or the following flags (BASSData):BASS_DATA_FLOAT Return floating-point sample data. BASS_DATA_FFT256 256 sample FFT (returns 128 floating-point values) BASS_DATA_FFT512 512 sample FFT (returns 256 floating-point values) BASS_DATA_FFT1024 1024 sample FFT (returns 512 floating-point values) BASS_DATA_FFT2048 2048 sample FFT (returns 1024 floating-point values) BASS_DATA_FFT4096 4096 sample FFT (returns 2048 floating-point values) BASS_DATA_FFT8192 8192 sample FFT (returns 4096 floating-point values) BASS_DATA_FFT_INDIVIDUAL Use this flag to request separate FFT data for each channel. The size of the data returned (as listed above) is multiplied by the number channels. BASS_DATA_FFT_NOWINDOW This flag can be used to prevent a hanning window being applied to the sample data when performing an FFT. BASS_DATA_AVAILABLE Query the amount of data the device has buffered (the BASS_WASAPI_BUFFER flag isn't required for this, buffer can be when using this flag).
Return Value
Type: Int32If an error occurs, -1 is returned, use BASS_ErrorGetCode to get the error code.
When requesting FFT data, the number of bytes read from the device (to perform the FFT) is returned.
When requesting sample data, the number of bytes written to buffer will be returned (not necessarily the same as the number of bytes read when using the BASS_DATA_FLOAT flag).
When using the BASS_DATA_AVAILABLE flag, the number of bytes in the device's buffer is returned.
This function is like the standard BASS_ChannelGetData(Int32, IntPtr, Int32), but it gets the data from the device's buffer instead of decoding it from a channel, which means that the device doesn't miss out on any data. In order to do this, the device must have buffering enabled, via the BASS_MIXER_CHAN_BUFFER flag.
Internally, a BASS stream is used for that, so the usual BASS_DATA_xxx flags are supported. That also means that BASS needs to have been initialized first; it specifically uses the "no sound" device. If the device is subsequently freed, this method call will fail.
As in BASS, simultaneously using multiple devices is supported in the BASSWASAPI API via a context switching system - instead of there being an extra "device" parameter in the function calls, the device to be used needs to be set via BASS_WASAPI_SetDevice(Int32) prior to calling the function. The device setting is local to the current thread, so calling functions with different devices simultaneously in multiple threads is not a problem.
With an output device, the BASS_DATA_AVAILABLE return value may be larger than the buffer size indicated by BASS_WASAPI_GetInfo(BASS_WASAPI_INFO) due to additional latency in the device/driver. When a mixer is feeding an output device, the BASS_DATA_AVAILABLE return value can be used with the BASS_ATTRIB_MIXER_LATENCY attribute and/or the BASS_Mixer_ChannelGetPositionEx(Int32, BASSMode, Int32) function, to have the mixer account for the latency in its source position reporting and data/level retrieval.
ERROR CODE | Description |
---|---|
BASS_ERROR_INIT | BASS_WASAPI_Init(Int32, Int32, Int32, BASSWASAPIInit, Single, Single, WASAPIPROC, IntPtr) has not been successfully called. |
BASS_ERROR_NOTAVAIL | The device was not initialized using buffering (BASS_WASAPI_BUFFER). |