Kinect AudioBeam层次结构 [英] Kinect AudioBeam Hierarchy

问题描述

您好，

我无法理解AudioBeam"Hierarchy"背后的想法。
$
AudioBeamFrameArrivedEvent内部： 

I am not getting the idea behind the AudioBeam "Hierarchy".
Inside the AudioBeamFrameArrivedEvent: 

我们首先需要获得AudioBeamFrameReference才能获得AudioBeamFrameList以便能够获得AudioBeamFrame以获得列表< AudioBeamSubFrame>最后我们浏览了每个AudioBeamSubFrame

We first need to get AudioBeamFrameReference to be able to get AudioBeamFrameList to be able to get AudioBeamFrame to be able to get a list<AudioBeamSubFrame> and finally we go through each AudioBeamSubFrame

为什么会这样？有人可以解释一下吗？如果有人可以解释什么是"框架"，我也会感激。在音频上下文中意味着什么？

Why is it like that ? Can someone explain it ? I would also appreciate if someone could explain what does "frame" mean in the Audio Context ?

为什么在AudioBeamFrameArrivedEvent中我们得到的似乎是一个帧列表而不是一个帧？即使这个"列表"也是如此。框架只包含一个框架

Why in the AudioBeamFrameArrivedEvent we get what seems to be a list of frames and not a single frame ? Even though this "list" of frames only contains one frame

谢谢

推荐答案

让我们从一般的音频源开始帮助你...

Let's start with the Audio source in general to help you...

Kinect设备包含4个以阵列方式设置的麦克风。这些麦克风中的每一个在非等距位置分开定位，使得当声波击中不同的麦克风时，它将在不同时间击中每个麦克风。达到所有不同麦克风所花费的
时间有助于Kinect确定声音来自的位置和角度。

The Kinect device contains 4 microphones setup in an array fashion. Each of these microphone are positioned apart in a non-equidistant location such that as sound waves hit the different microphones it will hit each microphone at different times. The amount of time it takes to reach all the different mic's helps the Kinect determine location and angle the sound comes from.

从编码角度来看，我们可以通过这些麦克风访问这些麦克风。 Kinect AudioSource接口。此AudioSource目前允许我们通过AudioBeam访问每个麦克风。 AudioBeam应该是麦克风之一。然而，目前很可能
来自每个暴露给我们作为1 AudioBeam的麦克风的累积总和/平均波样本。我们只提供麦克风阵列的第一个AudioBeam。很有可能在不久的将来，其他音频光束也可能会暴露给我们原始数据。

From a coding perspective we have access to these mic's through the Kinect AudioSource interface. This AudioSource at present gives us access to each mic through the AudioBeam. The AudioBeam is supposedly one of the mic's. However at present it is most likely an accumulated sum/avg of wave samples from each mic exposed to us as 1 AudioBeam. We are only give the first AudioBeam of the mic array. It is very well possible that the other Audio beams could be exposed to us as well for the raw data in the near future.

在C ++应用程序中，您可以为每个部分轮询AudioBeam从声音接收的波比特样本。或者您可以收听AudioBeam生成的事件，该事件可以让您知道何时收到完整的样本并且您可以阅读。

In a C++ application, you can poll the AudioBeam for each parts of a sample of wave bits received from the sound. Or you could listen for an event that the AudioBeam generates which lets you know when a full sample has been received and you can read that.

在C＃中，您通常会基于以下内容构建应用程序。事件。 C＃封装了C ++应用程序需要的一些血腥细节，并向我们提供了对AudioBeam类的引用 - 称为AudioBeamFrameReference。我对命名约定
的猜测更多是为了使其与其他源和帧保持一致：ColorFrame，DepthFrame，IRFrame等。因此，使用此AudioBeamFrameReference，我们再次呈现（"AudioBeams"的列表）。 ~mics ...），在C＃中称为AudioBeamFrameList。同样，对于这个
SDK版本，仅支持1（psuedo mic或AudioBeam），因此我们有AudioBeamFrameReference。

In C# you typically will build your application based on the Event. C# Encapsulates some of the gory details a C++ app would need and presents us with a reference to the AudioBeam class - known as the AudioBeamFrameReference. My guess as to the naming convention is more so to keep it aligned with the other sources and frames: ColorFrame, DepthFrame,IRFrame, etc. So with this AudioBeamFrameReference we again are presented with a list of ("AudioBeams" ~ mics...), it is called a AudioBeamFrameList in C#. Again for this SDK version only 1 (psuedo mic or AudioBeam ) is supported thus we have the AudioBeamFrameReference.

akward部分接下来......

The akward part comes next...

所以一旦我们有AudioBeam - 我们可以得到样本或部分样品。请记住使用C＃，它完成了事件，所以当AudioBeam告诉我们它为我们提供样本时，我们会得到一个样本。这是作为AudioBeamSubFrame呈现给我们的。帧
的概念在这里没有意义，除了它是"样本"之外。基于IEEE 16bit浮点16kHz的4Channel数据阵列。 subFrame的想法必须是在一个事件内可以在1秒或更长时间内发生，你可能有多个
"样本"。或者没有"样本"一点都不为了使设计与其他来源保持同步：ColorFrame，Depth，IR等，你仍然需要检查null。

So once we have the AudioBeam - we can get the sample or part of a sample. Remember with C# it's done with events so we get a sample when the AudioBeam tells us it has a sample for us. This is presented to us as a AudioBeamSubFrame. The concept of frame really makes no sense here other than it's a "Sample" based on IEEE 16bit floating point 16kHz 4Channel array of data. The idea of a subFrame would have to be that within an event would could take place in 1 second or more, you could potentially have multiple "samples" or no "samples" at all. To keep the design in sync with the other sources: ColorFrame, Depth, IR, etc you would still need to check for null.

这是我很难理解这一点 - 也许是K4W团队可以为此添加更多亮点。

This is my poor attempt to understand this - maybe the K4W team can add more light to this.

这篇关于Kinect AudioBeam层次结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！