In addition, the IAudioClient::Initialize method supports an AUDCLNT_STREAMFLAGS_EVENTCALLBACK flag that enables an application's buffer-servicing thread to schedule its execution to occur when a new buffer becomes available from the audio device. By using these features, an application thread can reduce uncertainty about when it will execute, thereby decreasing the risk of glitches in a low-latency audio stream.
*fx = (WAVEFORMATEX*)malloc(sizeof(WAVEFORMATEX)); (**fx).wFormatTag = WAVE_FORMAT_PCM; (**fx).cbSize = 0; (**fx).nAvgBytesPerSec = 44100 * 6; //for 16bit audio, it was '44100 * 4' (**fx).nBlockAlign = 6; //for 16bit audio, it was '4' (**fx).nChannels = 2; (**fx).nSamplesPerSec = 44100; (**fx).wBitsPerSample = 24; //for 16bit audio, it was '16'
Most devices using WASAPI prefer 24 bits padded to 32 bits per sample, or don't even care if you fill the lower bits with extra precision that'll possibly be thrown out anyway.
Formats that support more than two channels or sample sizes of more than 16 bits can be described in a WAVEFORMATEXTENSIBLE structure, which includes the WAVEFORMAT structure.
Ok, I see.I haven't had problems with my integrated realtek on a old laptop or my desktop, but as I say, I normally use floating mode.Said that, I recommend you to take a look at this part of the code, since it might be what knik said, which is an incorrect initialization of the waveformat:https://sourceforge.net/p/psycle/code/HEAD/tree/trunk/psycle/src/psycle/host/AudioDriver.cpp#l74
PrepareWaveFormat(fx,2, //nChannel48000, //Sampling Rate32, //bits24 //validBits);
PrepareWaveFormat(fx,2, //nChannel48000, //Sampling Rate24, //bits, meaning no byte padding.24 //validBits);
Then my last question, how can i know whether it needs a bottom-padding or top-padding ?Is it up to the CPU (x86) or to the audio chip (Realtek)?