禁用USB读管的垃圾收集

我正在尝试使用ftdi的d3xx.net从USB端口收集数据。收集数据,然后发送到一个快速傅立叶变换绘制频谱。即使您错过了一些数据,这也可以正常工作。你看不出来。但是,如果您希望将此数据发送到音频输出组件,则会注意到数据丢失。这就是我的问题所在。 数据被收集,然后发送到音频设备。所有数据包都在所需的时间范围内完成。但是,音频正在删除显示的数据。这是一张正弦波在音频输出时的样子的图片:

您可以看到一些数据在开始时丢失,而在接近结束时似乎整个周期都丢失了。这只是一个例子,它一直在变化。有时数据似乎不在那里。 我已经完成了整个处理链,我很确定声音的数据包正在生成。 从那以后我就用了JetBrains性能分析器。我发现如下:readpipe方法需要8.5毫秒,这正是您希望读取所需要的。到现在为止,一直都还不错。一旦readpipe命令完成,您将有0.5毫秒的时间来执行另一个readpipe,否则将丢失一些数据。查看探查器输出,我看到:

readpipe需要8.5毫秒,然后有一个用于垃圾收集的条目,平均需要1.6毫秒。如果确实偶尔发生这种情况,那么我丢失了一些数据。

下面是代码:它是一个后台工作人员:

private void collectdata(object sender,doWorkEventargs e)
{
同时(保持)
{
ftstatus=d32xdevice.readpipe(0x84,iqbuffer,65536,ref bytestransferred);//读取iq数据-将得到1024对-每个值2字节

_ waitForData.set();
}
}
< /代码> 

waithandle向另一个线程表示数据可用。
那么GC是导致数据丢失的原因吗?如果是这样,我怎么能避免呢?
谢谢!



您可以看到一些数据在开始时丢失,而在接近结束时似乎整个周期都丢失了。这只是一个例子,它一直在变化。有时数据似乎不在那里。
我已经完成了整个处理链,我很确定声音的数据包正在生成。
从那以后我就用了JetBrains性能分析器。我发现如下:readpipe方法需要8.5毫秒,这正是您希望读取所需要的。到现在为止,一直都还不错。一旦readpipe命令完成,您将有0.5毫秒的时间来执行另一个readpipe,否则将丢失一些数据。查看探查器输出,我看到:



读取管道需要8.5毫秒,然后有一个垃圾收集条目,平均需要1.6毫秒。如果确实偶尔发生这种情况,那么我就丢失了一些数据。

下面是代码:它是一个后台工作人员:

    private void CollectData(object sender, DoWorkEventArgs e)
    {
        while (keepGoing)
        {
            ftStatus = d3xxDevice.ReadPipe(0x84, iqBuffer, 65536, ref bytesTransferred); //read IQ data - will get 1024 pairs - 2 bytes per value

            _waitForData.Set();
        }
    }


waithandle向另一个线程表示数据可用。
那么GC是导致数据丢失的原因吗?如果是这样,我怎么能避免呢?
谢谢!