音视频驱动的问题

zouzheng

想请教一下：把音视频驱动做成一个设备文件？这样的方案好不好？
如果要这样做，要怎样把音频模块驱动的操作和视频模块驱动的操作加到这个驱动上来？

Godbach

原帖由 zouzheng 于 2008-11-12 19:35 发表
想请教一下：把音视频驱动做成一个设备文件？这样的方案好不好？
如果要这样做，要怎样把音频模块驱动的操作和视频模块驱动的操作加到这个驱动上来？

把驱动做成一个文件，什么意思。通常的方式都驱动程序通过申请一个设备号来实现吧。在这个设备上注册read，write以及ioctl，open，release操作即可

zouzheng

一般来说,我们是把音频和视频分别写一个驱动,在dev目录下分别生成它们自己的设备文件,现在我们要求把这两个模块写成一个驱动,也就是生成一个设备文件

Godbach

原帖由 zouzheng 于 2008-11-12 19:45 发表
一般来说,我们是把音频和视频分别写一个驱动,在dev目录下分别生成它们自己的设备文件,现在我们要求把这两个模块写成一个驱动,也就是生成一个设备文件

明白LZ的意思了。很惭愧刚才没看清楚是要吧音频和视频做成一个设备文件。

那这样的话就涉及到read和write的时候具体操作哪个具体硬件设备的问题了吧

dreamice

原帖由 zouzheng 于 2008-11-12 19:35 发表
想请教一下：把音视频驱动做成一个设备文件？这样的方案好不好？
如果要这样做，要怎样把音频模块驱动的操作和视频模块驱动的操作加到这个驱动上来？

你不是想把音视频的编解码都做到驱动里面吧？这样就不太合理了。关于音视频，我觉得这是一个上层的概念，对于驱动层，它只需要关注你的数据流或者说数据包，驱动只需要把这个数据包传递给你的应用程序即可。
如果这样一种应用，那么，我觉得做成一个设备文件的意义不是太大。我觉得合理的实现是，跑一个daemon进程，来解码，驱动程序只需要与daemon进程之间通信就是了。这种通信的实现方式就多种多样了。

Godbach

我觉得LZ是想把音频视频的驱动程序在init的时候申请一个设备号。用一个设备文件实现呢

dreamice

有时候做驱动考虑到应用的时候，就不太好做了，容易让人搞混，呵呵。

samon_fu

驱动是驱动，不要考虑应用，如果考虑了，操作系统里的分层概念也就没了，这个可是操作系统的精华啊。
当然，如果你考虑做几个特殊接口给上面方便使用的话，这个可以考虑，比如vfork对于fork的改进。

对于音频、视频是否做成一个文件我觉得肯定不合适，操作系统那么多年了，如果合适早就有人做了，现在还是分开的，肯定有其理由的。

个人认为其理由是：视频、音频设备有很多种，很多种搭配来使用，操作系统是个通用型的概念的，所以框架方面肯定是分开的。

如果你觉得把视频、音频做到一起，来使用系统提供的框架来搞，肯定也是可行的，只是你的驱动就失去了通用性，而且也不是现在的主流。当然，如果出于市场利益（如保护你的驱动，虽然按照gpl是不行的），一定要按你说的做到一起，那就搞呗～～～，有了市场利益（老大让搞），哪里有不能呢，呵呵:wink:


具体要做的话，可能就要加一层的概念在里面了，你实际的pci设备（音频、视频）获得后，先别注册到系统中，这个时候传给一个虚拟音视频驱动，由该虚拟来注册成一个特殊的设备（需要纳入到系统框架中，如选择使用视频的），再在你的虚拟驱动中开几个口子，分别指向到对应的音频、视频设备的对应具体的接口去。

说实话，感觉挺恶的，真没啥实际意义的。你往上层暴露出去的接口还要和现在的音视频框架一致的，要不然上层软件没法用。

[ 本帖最后由 samon_fu 于 2008-11-12 21:56 编辑 ]

marco_hxj

the audio driver should implement the Advanced Linux Sound Architecture driver,which is OSS-compatible

zouzheng

原帖由 samon_fu 于 2008-11-12 21:51 发表
驱动是驱动，不要考虑应用，如果考虑了，操作系统里的分层概念也就没了，这个可是操作系统的精华啊。
当然，如果你考虑做几个特殊接口给上面方便使用的话，这个可以考虑，比如vfork对于fork的改进。

对于音 ...

对于我个人理解音频、视频、解复用驱动都是分开做，分别生成一个设备文件，可是我们这里来了位10工作经验的老大，提出把音视频、解复用三个模块作为一个驱动来开发，个人认为相当于把三块芯片（音频解码、视频解码、解复用）做成一个驱动，那位老大就是站在应用的角度考虑，也不知道他是否是Linux驱动高手，反正我是没有见过这样的驱动开发方式，他就是为了应用方便，还晕的是这三个模块要提供一样API接口，不同硬件设备肯定有不同操作步骤。我也觉得不合适。
“使用系统提供的框架来搞”你说的对，他就是弄一个框架，把本来的如音频驱动理解成模块，还有什么属性之类的，完全以C++的思想（对象、方法）考虑驱动，一开始看到这样的方案，我有非常强的排斥感，非常不敢苟同那种方案。
你说的通用性是什么意思？他说他的这种方案通用性好，同系列的芯片很好通用，没有什么保护驱动的意思，就是很反对这种方案估计还是要那样做，现在就是不知道咋那样做？在一块驱动里要把音频、视频、解复用都要注册进去，但只生成一个设备文件，每个模块还都要IO映射、初始化工作，每个模块还有自己操作？没看见有什么可供参考的例子。
“具体要做的话，可能就要加一层的概念在里面了，你实际的pci设备（音频、视频）获得后，先别注册到系统中，这个时候传给一个虚拟音视频驱动，由该虚拟来注册成一个特殊的设备（需要纳入到系统框架中，如选择使用视频的），再在你的虚拟驱动中开几个口子，分别指向到对应的音频、视频设备的对应具体的接口去。
”我这里的音频、视频、解复用都是主芯片（ARM9的）集成在里面的，个人理解这三个模块相当于三个外设，你后面的想法有点看不懂哦，能不能详细指导下？我目前的想法先注册一个设备文件，然后在初始化的时候或者probe的时候再分别调用音频、视频、解复用的注册（但这个注册不会生成设备文件），但是音频、视频、解复用都要初始化和ioremap动作，这个放在哪里好？放在驱动的初始化里还是音视频、解复用的注册所调用的函数里？
哎，不知道怎么搞？感觉是明显增加驱动的复杂度