[发明专利]嵌入式设备的音频管理装置及方法

说明书

技术领域

本发明涉及一种在嵌入式设备(比如手机)上实现便于第三方程序移植的音频管理的技术。

背景技术

目前运行在手机终端上的最典型的操作系统是Linux和WinCE。以Linux为例，一般应用是与操作系统进行交互，这些应用都是通过操作系统提供的接口(比如驱动程序接口)进行操作。例如，应用程序要播放声音，就要与声卡(音频，下同)驱动程序交互，一般要通过调用open()、ioctl()、write()、read()、close()等函数来操作声卡。普通的系统音频结构，如图1所示。简单的嵌入式系统与功能强大的PC机有很大的区别，比如，简单的声卡设备，不允许多个应用同时打开声卡，同时播放声音，也就是说如果一个应用正在使用声卡，则另外的应用就无法使用声卡，只有等待前一个应用使用完将声卡关闭后才能使用。这个问题不是不能解决，比如，不允许多个应用同时打开声卡，是因为声卡设备只有一个，如果增加声卡硬件设备，就可以解决这个问题，不过这样会导致成本的增加，因此一般很少使用。

另外手机上的音频管理有其独有的特点：

一个典型的手机终端，用户使用时会有许多场景，比如来电、打电话中、MP3播放中、接收短消息、响闹铃中等等。这些场景，可能单独发生，也有可能同时发生，比如正在播放MP3，此时闹铃响了，或者来电话了，又或者来短消息了等等，因此手机软件开发时，必然要考虑到如来电铃音、按键音、闹铃音、短消息提示音、MP3音乐等等各种声音需要播放。但是这些声音又有各不相同的特点，比如，来电铃音，可以说是实时的，优先级最高的，不论当时在做什么，只要有来电，就必须马上播铃音提示，并且不能中间打断；而按键音的特点是优先级比较低，一般正在播放其它声音的时候，可以不播按键音；MP3音乐的特点是播放时间一般很长，在播放期间，可能发生其它很多事情，有很多其它声音需要播放，一般来说，MP3音乐此时应该暂停。许多场景并发时就会遇到我们前面说的问题：一个应用正在使用声卡，会使后面所有的应用都无法及时使用声卡。

解决该问题的办法有很多，如：

可以使用一个单独的服务程序，负责对声卡设备进行管理，对各种声音进行有优先级的排队，优先级高的声音先播放。该服务程序，可以放在应用层，如图2中的音频管理模块，对声卡的操作都由此服务程序完成，其它任何应用不应该自己操作声卡，其它应用只能通过向服务程序发消息的方法通知服务程序执行相应的操作。不过这种方法也有缺点，一是此服务程序实现复杂，要考虑多种情况，比如，对简单的铃音，可以直接使用文件名做消息参数，由服务程序自己调用codec(编解码器)解压，由其操作声卡播放；对于MP3音乐，由于一般MP3播放器自己就已经调用codec将数据解压了，因此服务程序只须将解开的数据直接写到声卡播放就行了，但是这个数据如何从媒体播放器传递到服务程序也存在问题，毕竟这是两个不同的进程，需要传输的数据量又非常大，这样需要复杂的进程间通讯和同步机制、进程间大量数据传输机制；二是这个方法不便于移植其它程序到系统，原因很简单，比如要移植一个游戏到系统，由于所有的游戏都是直接操作声卡播放声音的，因此显然是与系统冲突的，这给移植带来很大的麻烦；有第三方移植程序的时候，如果把第三方程序也当成普通应用，则系统结构图仍旧如图2所示，但是这个方案显然要对第三方程序做大的修改；如果让第三方程序直接访问驱动程序，则系统结构图如图3所示，这种方案显然会导致音频管理冲突。

也可以将这些复杂的音频管理逻辑全部写入音频驱动程序，尽量保证驱动程序的接口不做变化，如图4所示。这种方法的优点在于第三方程序的移植方便了，但它具有下列明显缺点：一是对音频驱动要进行很大的改动，这是系统不稳定的重要因素；二是将不应该由驱动做的事情，做到了驱动里，导致整个系统结构不清晰，逻辑混乱，驱动和上层应用严重相互依赖，不利于移植和扩展，不利于独立发展。

因此，需要一种嵌入式设备的音频管理的解决方案，能够解决上述相关技术中的问题。

发明内容

本发明的目的是提出一种使用伪驱动方便手机等设备上第三方程序移植的音频管理的方案，即通过在驱动程序里做一个虚的音频设备，来避免第三方程序由于直接操作声卡而导致系统音频管理冲突。

根据本发明的一个方面，提供了一种嵌入式设备的音频管理装置，包括用于驱动声卡工作的音频驱动模块，该音频管理装置还包括：虚拟音频驱动模块，用于在同步模块的控制下响应于第三方的操作来驱动声卡工作；以及同步模块，用于根据音频驱动模块的工作状态来控制虚拟音频驱动模块的运行。