我使用 WAVEFORMATEXTENSIBLE 结构捕获了原始音频数据流。 WAVEFORMATEXTENSIBLE 如下图所示:
在standard的wav文件之后,我尝试将原始位写入wav文件。 我所做的是:
写“RIFF”。
写一个DWORD。 (filesize - sizeof(“RIFF”) - sizeof(DWORD))。
=== WaveFormat Chunk ===
写“WAVEfmt”
写一个DWORD。 (WAVEFORMATEXTENSIBLE结构的大小)
编写WAVEFORMATEXTENSIBLE struct。
=== Fact Chunk ===
写“fact”
写一个DWORD。 (4)
写一个DWORD。 (流中的样本数量,应为sizeof(rawdata)* 8 / wBitsPerSample)。
===数据块===
答案 0 :(得分:0)
我想出来了,似乎IAudioRenderClient中的getbuffer releasebuffer循环放置的原始数据格式与传递给IAudioClient的initialize方法的格式相同。
在我的情况下,IAudioClient中的GetMixFormat与传递给initialize方法的格式不同。我认为GetMixFormat获取设备支持的格式。
IAudioClient应该已经完成了格式从初始化格式到mixformat的转换。我拦截了initialize方法,得到了格式,它就像一个魅力。
答案 1 :(得分:0)
我正在拦截 WASAPI 以访问音频数据并面临完全相同的问题,即从数据生成的音频文件听起来像是正确的内容,但尽管帧速率、样本宽度、通道数等不正常,但不知何故却非常嘈杂。设置正确。
WAVEFORMATEXTENSIBLE 的 SubFormat 字段显示数据实际上是 KSDATAFORMAT_SUBTYPE_IEEE_FLOAT,而我本来是把它当作整数来处理的。根据{{3}},KSDATAFORMAT_SUBTYPE_IEEE_FLOAT 等价于 WAVEFORMATEX 中的 WAVE_FORMAT_IEEE_FLOAT。因此,将 wav 文件的 fmt 块(通常从第 20 个位置开始)中的“音频格式”设置为 WAVE_FORMAT_IEEE_FLOAT(即 3)解决了问题。记得把它放在小端。