Biu~ 经过了几篇博文对chain的介绍，估计大概可能maybe大家对这个功能的使用有了一定的了解吧，而这一篇主要是对chain中的一个filter的用法做一个解析，这个filter目前只在sink中的chain用到，earbud及后面的新adk都没有用到。Emmmmm~虽然后续可能不会用到，但在改写sink的chain时，他却可以起到很大的绊脚石作用。我们还是简单的了解一下这个filter的用法吧。
首先，这个filter的作用是过滤chain中没用的模块（operator），为什么是没用呢？因为有人懒，想复用一部分代码，就写了一个他认为这个模式下最全的音频处理链路chain。后续如果有在这种模式下工作的chain，但又不需要全部功能，就可以用filter筛选掉没用的模块。嗯，就是这样→_→。
这里用usb audio的voice模式和hfp通话作为例子，请在下面两图中找茬
可以很明显看出，头尾两端负责发送和接受的模块不一样，其他的都一模一样，连接也一样。这就是使用filter复用chain的效果。
回到代码部分，我们先看chain部分，chain的链路声明在audio_voice_common_config.c这个文件里面，其他部分的讲解在上几篇博文有介绍，这里主要讲模块声明部分
在这个声明中，我们能看到他是创建一个模块并给予别名（相当于编了个号，便于代码使用），而这里有的写了id，有的就没有写（capability_id_none为无指定id）。如果没有写id的话，这个模块是不被创建的，因为系统并不知道要创建什么。这里面的receive_role和send_role是链路的重要角色，不能不创建，这里只是留了个空白坑，到后面会把这个坑填上id，这个填充的地方就是在filter中实现。
这里要阐述一下filter工作机制，filter其实也是和上面的声明一样，声明一堆要创建的模块，但这里他只是声明要填充上面chain的那部分模块，并且id和别名都是确定、完整的。 Filter会去筛选chain中id为none的模块，再用这些id为none的别名和filter中的模块别名对比，如果有一致的话，就补充filter中别名对应的id给chain，如果没有一致的就放弃填充，chain也就不会创建对应的模块。所以在filter列表中一定有receive_role和send_role这两个角色。至于例子中的filter，在audio_input_usb_connect.c这个文件里面有usb filter的模块声明
这里面是带参数地创建了两个模块，分别是收和发，并且都是带有id的
Hfp的filter也一样，在audio_voice_hfp_connect.c中就可以看到
但别名和上面chain中写的对不上。其实这个别名是有关联的，只是名字不一样而已，在audio_voice_common_config.h中就有声明，
每个filter都通过getOperatorFilter这个接口返回到上层getFilters中，在这里给到operator_filters_t的结构体中保存，这里面有个filter模块的个数，写了2，如果要加自己的filter，记得修改这个数字
最后这个filter结构体会用在ChainCreateWithFilter这个函数中创建一个符合要求的chain。
上面是filter简单的应用，因为收发是一定要的模块，所以一定有对应的filter，但是有些模块不是必须的，例如上面chain中就有一个别名为rate_adjustment_send_role这个模块，这个模块他是根据当前链路情况才去判断要不要用的，在audio_voice_common_dsp.c中的createOperators函数中就有写。
如果当前需要这个模块，就会在原有的filter基础上上添加这个模块的filter。除了要在原有的filter上添加，其他的声明、获取这些都是一样的，这部分不再冗诉。
以上是本期博文的全部内容，如有疑问就别在博文下方评论留言了，有什么疑问或想了解的当面和我说（如果你知道我是谁的话ヽ(￣▽￣)و），我会尽量安排上(o´ω`o)و。谢谢大家浏览，我们下期再见。
简单是长期努力的结果，而不是起点
—— 不是我说的
评论