CN109669691B - 基于嵌入式Linux音频播放器的平台通用控制方法及系统 - Google Patents

Abstract

本发明公开一种基于嵌入式Linux音频播放器的平台通用控制方法及系统，其中该方法包括：基于系统业务层，获取用户播放操作指令；基于与所述系统业务层对接的播放器控制接口层，确定与所述用户播放操作指令相对应的本地播放器调用接口，其中所述播放器控制接口层配置有多个与系统硬件平台的本地播放器相关联的本地播放器调用接口；基于所确定的本地播放器调用接口，调用系统硬件平台的本地播放器执行相应的操作。由此，通过在系统业务层和平台硬件播放器层之间设置播放器控制接口层，屏蔽了不同硬件平台之间的差异性，并应用接口技术本地播放器和业务层进行关联，无需对业务层作出大量的代码修改，极大降低了开发压力，缩短产品研发周期。

Description

基于嵌入式Linux音频播放器的平台通用控制方法及系统

技术领域

本发明属于嵌入式Linux播放器应用技术领域，尤其涉及一种基于嵌入式Linux音频播放器的平台通用控制方法及系统。

背景技术

随着计算机技术、通信技术的飞速发展和3C(计算机、通信、消费电子)的融合,嵌入式系统已经渗透到各个领域。随着嵌入式渗透到各个领域，特别是随着智能语音的发展，智能音箱、智能早教机等等一批无屏嵌入式设备的普及，对于嵌入式Linux播放器的要求越来越高。

对于嵌入式Linux播放器，不仅仅是在流媒体播放、多种格式支持、重采样等性能和功能上要求越来越高，同时对开发周期、迭代速度要求也越来越高。但是由于嵌入式硬件平台众多、软件平台繁杂，导致业务在不同平台上的部署受到极大的牵制和约束，无法快速的进行产品业务的迁移，其中不同硬件平台播放器差异是其中一个重要原因。

目前相关技术中，为了实现嵌入式Linux播放器在不同的嵌入式硬件平台或软件平台之间进行复用，一般是基于开源解码库(如：ffmepg、libmad等)，然后自行控制音频流，首先从文件或网络中获取未解码的音频流，然后将未解码的音频流送入解码库当中，再将已经解码的PCM数据送入到音频驱动中进行播放。基于开源的播放器(如：mplayer)，根据用户需求的硬件特性修改后的进行移植。

但是，本申请的发明人在实践本申请的过程中发现上述现有技术至少存在如下的缺陷：该处理方法只是基于用户需求根据开源项目进行音频数据流处理，或者只能提供有限的播放方法，导致其无法满足日益多元化的播放需求。例如，当客户需要将整个播放器的流程进行重新设计时，则无法快速响应客户定制需求，同时在切换硬件平台或者切换系统的时候，会导致大量重复工作和开发资源的浪费。

发明内容

本发明实施例提供一种基于嵌入式Linux音频播放器的平台通用控制方法及系统，用于至少解决上述技术问题之一。

第一方面，本发明实施例提供一种基于嵌入式Linux音频播放器的平台通用控制方法，包括：基于系统业务层，获取用户播放操作指令；基于与所述系统业务层对接的播放器控制接口层，确定与所述用户播放操作指令相对应的本地播放器调用接口，其中所述播放器控制接口层配置有多个与系统硬件平台的本地播放器相关联的本地播放器调用接口；基于所确定的本地播放器调用接口，调用系统硬件平台的本地播放器执行相应的操作。

第二方面，本发明实施例提供一种基于嵌入式Linux音频播放器的平台通用控制系统，所述系统包括：指令获取程序模块，用于基于系统业务层，获取用户播放操作指令；播放器控制接口层调用程序模块，用于基于与所述系统业务层对接的播放器控制接口层，确定与所述用户播放操作指令相对应的本地播放器调用接口，其中所述播放器控制接口层配置有多个与系统硬件平台的本地播放器相关联的本地播放器调用接口；本地播放器调用程序模块，用于基于所确定的本地播放器调用接口，调用系统硬件平台的本地播放器执行相应的操作。

第三方面，本发明实施例提供一种电子设备，其包括：至少一个处理器，以及与所述至少一个处理器通信连接的存储器，其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述方法的步骤。

第四方面，本发明实施例提供一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述方法的步骤。

本发明实施例的有益效果在于：通过在系统业务层和平台硬件播放器层之间设置播放器控制接口层，阻断了在业务层与播放器层之间的直接沟通，屏蔽了不同硬件平台之间的差异性，并应用接口技术实现了在本地播放器和业务层之间的关联操作，使得嵌入式Linux音频播放器能够在多个不同硬件平台之间复用，只需要在播放器控制接口层的接口代码上进行相应调整，而无需对业务层作出大量的代码修改和配置，极大降低了开发压力，缩短产品研发、测试周期。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明一实施例的基于嵌入式Linux音频播放器的平台通用控制方法的流程图；

图2为图1所示基于嵌入式Linux音频播放器的平台通用控制方法中S12在一示例下的原理执行流程图；

图3为本发明一实施例的基于嵌入式Linux音频播放器的平台通用控制方法用于实现播放拓展功能的在一示例下的原理执行流程图；

图4为应用本发明一实施例的基于嵌入式Linux音频播放器的平台通用控制方法在一示例下的架构示意图；

图5为本发明一实施例的基于嵌入式Linux音频播放器的平台通用控制系统的结构框图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

本发明可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、元件、数据结构等等。也可以在分布式计算环境中实践本发明，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

在本发明中，“模块”、“系统”等等指应用于计算机的相关实体，如硬件、硬件和软件的组合、软件或执行中的软件等。详细地说，例如，元件可以、但不限于是运行于处理器的过程、处理器、对象、可执行元件、执行线程、程序和/或计算机。还有，运行于服务器上的应用程序或脚本程序、服务器都可以是元件。一个或多个元件可在执行的过程和/或线程中，并且元件可以在一台计算机上本地化和/或分布在两台或多台计算机之间，并可以由各种计算机可读介质运行。元件还可以根据具有一个或多个数据包的信号，例如，来自一个与本地系统、分布式系统中另一元件交互的，和/或在因特网的网络通过信号与其它系统交互的数据的信号通过本地和/或远程过程来进行通信。

最后，还需要说明的是，在本文中，术语“包括”、“包含”，不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

如图1所示，本发明的一实施例的基于嵌入式Linux音频播放器的平台通用控制方法，包括：

S11、基于系统业务层，获取用户播放操作指令。

关于本发明实施例方法的执行主体，其可以是被应用在装设有嵌入式Linux播放器的各式终端中，例如该终端可以是智能音箱、智能早教机等等。在终端可以是搭设有各式的嵌入式芯片，且对应于不同嵌入式芯片的硬件特性所对应的编解码库也会存在差异，而使得嵌入式Linux播放器在不同的硬件平台被使用时会导致业务层需要作出大量的修改以适配，严重影响了产品的研发周期并增大了研发成本。有鉴于此，本发明实施例方法旨在在不同的平台之间复用嵌入式Linux播放器，解决已有技术无法通用，在不同硬件平台、不同软件版本的情况下，需要进行的重复进行的播放器移植适配工作的问题。

具体的，系统业务层可以是指示用于与用户进行交互的层面，例如用户能够通过操作终端从而向终端发出相应的用户播放操作指令；关于该用户操作指令，其可以是对应开始播放、暂停播放、显示歌曲信息的指令。

S12、基于与系统业务层对接的播放器控制接口层，确定与用户播放操作指令相对应的本地播放器调用接口。

其中，播放器控制接口层配置有多个与系统硬件平台的本地播放器相关联的本地播放器调用接口。因此，利用与用户播放操作指令相对应的本地播放器调用接口，实现了对系统硬件平台的本地播放器的关联(例如对本地播放器的播放接口、暂停接口等进行关联)，使得播放器控制接口层在系统硬件层和系统业务层之间充当了中间层，其从系统业务层确定对应用户操作的接口，并利用该接口调用本地播放器，因此屏蔽了系统平台硬件层及业务层的差异性，实现了在不同系统硬件平台通用控制播放器的功能。

具体的，播放器控制接口层中的本地播放器调用接口和系统硬件平台的本地播放器通过如图2所示的流程进行关联：S121、获取系统硬件平台的本地播放器特征信息；S122、基于本地播放器特征信息，构建用于调用系统硬件平台的本地播放器的本地播放器调用接口。其中，该本地播放器特征信息可以是指示系统硬件平台标识信息及版本号，因此可以根据具体本地播放器进行差异化匹配。

作为示例，构建本地播放器调用接口的过程可以是对本地播放器建立回调关联关系的过程；作为示例，其可以是首先确定与本地播放器特征信息相匹配的回调特征信息，然后基于回调特征信息构建本地播放器调用接口，其中该本地播放器调用接口用于以回调的方式来调用系统硬件平台的本地播放器。

需说明的是，一些本地播放器在收到用户操作时需要进行预处理(例如先执行prepare函数)之后才可以运行，此时在回调时也应该做出相应的改进；例如，当本地播放器特征信息指示在系统硬件平台的本地播放器被调用之前需要进行预处理时，基于回调特征信息构建本地播放器调用接口，其中该本地播放器调用接口用于在调用系统硬件平台的本地播放器之前预处理该本地播放器，例如可以是预先执行prepare函数。

S13、基于所确定的本地播放器调用接口，调用系统硬件平台的本地播放器执行相应的操作。

在一些应用场景下，本地播放器调用接口包括本地播放器播放控制接口、本地播放器暂停播放控制接口和/或本地播放器释放控制接口等等。作为示例，当用户操作终端选择执行播放器播放功能时，基于统一的播放器控制接口层向业务层，确定相应的播放器播放控制调用接口，进而使用该播放器播放控制调用接口调用底层的系统平台的播放本地播放器播放接口以执行播放操作；相似地，还可以响应用户操作而实现播放暂停功能、歌曲释放功能，来执行播放暂停等操作。

在本发明实施例中，通过在系统的业务层和硬件播放器层之间设置播放器控制接口层，阻断了在业务层与播放器层之间的直接沟通，屏蔽了各个硬件平台的差异，并应用接口技术实现了在本地播放器和业务层之间的关联操作，使得嵌入式Linux音频播放器能够在多个不同硬件平台之间复用，只需要在播放器控制接口层的接口代码上进行相应调整，而无需对业务层作出大量的代码修改和配置，极大降低了开发压力，缩短产品研发、测试周期。

作为本发明实施例的进一步的公开和优化，由于人们对于播放体验的不断提升，仅由硬件平台的播放器上所提供的播放器功能已经无法满足日常用户需求，需要为播放器继续添加拓展功能。在目前相关技术中，依然是需要对不同的平台分别执行业务上的大量修改，且在不同的平台之间无法复用或通用。有鉴于此，本发明实施例还提出了：可以是在播放器控制接口层中还配置多个用于获取播放操作信息的拓展播放接口。作为示例，如图3所示的流程，包括：

S31、基于系统业务层，获取用户播放操作指令。

S32、当用户播放操作指令用于指示播放器拓展功能时，确定与用户播放操作指令相对应的拓展播放接口。

其中播放器控制接口层还配置有多个用于获取播放操作信息的拓展播放接口。具体的，播放操作信息可以是指示各类与播放操作相关的信息，例如播放状态信息(当前处于暂停、播放状态)，以及其还可以是指示播放歌曲信息。

S33、基于所确定的拓展播放接口，获取相应的播放操作信息。

具体的，该拓展播放接口可以是对接于本地资源库的接口，以从本地资源库中获取相应的播放操作信息；作为可替换或可附加地，其还可以是从远程终端或远程服务器来获取相应的播放操作信息等，且以上实施方式都属于本发明的保护范围内。

S34、将播放操作信息传递至系统业务层。

作为示例，当用户操作终端选择播放器拓展功能(例如播放歌曲信息)时，可以是确定相应的播放歌曲信息接口，并使用该播放歌曲信息接口获取播放歌曲的信息，然后将该播放歌曲的信息提供给系统业务层。

通过本发明实施例，基于播放器控制接口层还实现了对系统本地播放器功能的拓展；进一步的，当本发明实施例方法被应用在不同的硬件平台时，还能够借助播放器控制接口层实现了对拓展功能的复用和通用，而无需对业务层作出大量的代码修改和配置，更加优化了产品的开发速度。

如图4所示，应用本发明一实施例的基于嵌入式Linux音频播放器的平台通用控制方法的示例性架构，其中播放器控制模块处于中间层，起到中介作用，主要起到屏蔽本地系统播放器差异，进一步的还能够向上提供业务层迫切需要而本地播放器没有提供的拓展功能。

关于该架构的具体工作原理可以是：

1.向业务层提供统一的播放器控制接口

1)audio_manger_init

播放器控制模块初始化接口，主要作为初始化使用，返回控制模块的指针，作为后续API的参数使用。

2)audio_manger_play

播放器控制模块播放接口，业务层统一调用此接口进行播放功能，屏蔽不同平台播放接口差异。

3)audio_manger_pause

播放器控制模块播放接口，业务层统一调用此接口实现暂停功能。

4)audio_manger_set_play_mode

播放器播放模式接口，统一向业务层提供循环播放、顺序播放、随机播放等等播放模式。

5)audio_manger_deinit

播放器控制模块销毁接口，业务结束退出的时候调用。

2.解决不同平台播放器接口差异问题

上述几个接口统一了业务层接口，业务层无需直接调用系统原生播放器，即业务层无需代码改动，只需要根据具体平台的播放器接口修改播放器控制模块的部分代码即可。

下面说明上述接口如何屏蔽各个硬件平台的差异。

1).audio_manger_init

首先初始化播放器控制模块自身需要用到的部分，然后通过回调函数的方式调用系统提供播放器初始化接口。

2).audio_manger_play

此函数部分可根据具体本地播放器进行差异化匹配，首先初始化播放器控制模块自身需要控制的部分后，同样通过回调的方式调用。举例说明：

其一，某些播放器对本地内容和在线内容调用的接口不同，此部分可在回调函数中进行匹配，不同类型的字符串调用不同本地播放器接口即可。

其二，某些播放器在播放之前，需要调用prepare函数进行准备，然后调用start进行真正的播放，此部分流程同样可以在回调中进行实现。

播放接口是播放器中核心接口内容，由于各个厂家实现基本都不相同，部分即可通过回调的方式进行差异化的屏蔽，做到代码松耦合。

3).audio_manger_pause

此函数部分，各个厂家基本都是一个接口实现，调用本地播放器的暂停接口接口，如有特殊实现，同样通过回调的方式实现。

4).audio_manger_set_play_mode

此函数部分和本地播放器关系不大，主要是播放器控制模块拿到播放列表之后，按照用户设定的播放模式进行播放，默认支持循环播放、顺序播放、随机播放和单曲循环等等播放模式。

5).audio_manger_deinit

首先释放播放器控制模块自身申请的资源，然后通过回调函数的方式调用系统提供播放器释放资源接口，释放本地播放器申请的资源。

3.拓展原生播放器不支持的功能

大部分系统播放器只是实现播放功能，没有向业务层提供目前播放器状态，目前播放内容的具体信息等等，业务端迫切需要的功能。

播放器模块可通过以下两个标准接口向业务端提供上述业务：

1).get_player_status

业务端通过此接口获取播放器当前状态，例如：播放、暂停、恢复、停止等等状态，业务代码可通过此状态对业务精细化处理。

2).get_current_media_content

业务端通过此接口获取当前播放器播放内容的具体信息，例如：歌手、时长、歌曲类型等等信息。

由此，在本发明实施例架构中，通过播放器控制模块提供一种机制，也就是模糊底层硬件引起的播放器差异，同时向上统一提供业务端需要的业务。

如图5所示，本发明一实施例的基于嵌入式Linux音频播放器的平台通用控制系统500，包括

指令获取程序模块501，用于基于系统业务层，获取用户播放操作指令；

播放器控制接口层调用程序模块502，用于基于与所述系统业务层对接的播放器控制接口层，确定与所述用户播放操作指令相对应的本地播放器调用接口，其中所述播放器控制接口层配置有多个与系统硬件平台的本地播放器相关联的本地播放器调用接口；

本地播放器调用程序模块503，用于基于所确定的本地播放器调用接口，调用系统硬件平台的本地播放器执行相应的操作。

上述本发明实施例的系统可用于执行本发明中相应的方法实施例，并相应的达到上述本发明方法实施例所达到的技术效果，这里不再赘述。

本发明实施例中可以通过硬件处理器(hardware processor)来实现相关功能模块。

另一方面，本发明实施例提供一种存储介质，其上存储有计算机程序，该程序被处理器执行如上在基于嵌入式Linux音频播放器的平台通用控制方法中的步骤。

上述产品可执行本申请实施例所提供的方法，具备执行方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本申请实施例所提供的方法。

本申请实施例的客户端以多种形式存在，包括但不限于:

(1)移动通信设备:这类设备的特点是具备移动通信功能，并且以提供话音、数据通信为主要目标。这类终端包括:智能手机(例如iPhone)、多媒体手机、功能性手机，以及低端手机等。

(2)超移动个人计算机设备:这类设备属于个人计算机的范畴，有计算和处理功能，一般也具备移动上网特性。这类终端包括:PDA、MID和UMPC设备等，例如iPad。

(3)便携式娱乐设备:这类设备可以显示和播放多媒体内容。该类设备包括:音频、视频播放器(例如iPod)，掌上游戏机，电子书，以及智能玩具和便携式车载导航设备。

(4)其他具有数据交互功能的电子装置。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (8)

1.一种基于嵌入式Linux音频播放器的平台通用控制方法，包括：

基于系统业务层，获取用户播放操作指令；

基于与所述系统业务层通过相应接口对接的播放器控制接口层，确定与所述用户播放操作指令相对应的本地播放器调用接口，其中所述播放器控制接口层配置有多个与系统硬件平台的本地播放器相关联的本地播放器调用接口，其中，所述播放器控制接口层中的所述本地播放器调用接口和所述系统硬件平台的所述本地播放器通过以下方式进行关联：

获取所述系统硬件平台的本地播放器特征信息；所述本地播放器特征信息包括系统硬件平台标识信息和版本号；

基于所述本地播放器特征信息，构建用于调用所述系统硬件平台的本地播放器的本地播放器调用接口；

基于所确定的本地播放器调用接口，调用系统硬件平台的本地播放器执行相应的操作；

当所述用户播放操作指令用于指示播放器拓展功能时，确定与所述用户播放操作指令相对应的拓展播放接口，其中所述播放器控制接口层还配置有多个用于获取播放操作信息的拓展播放接口；

基于所确定的拓展播放接口，获取相应的播放操作信息；以及

将所述播放操作信息传递至所述系统业务层。

2.根据权利要求1所述的方法，其中，所述基于所述本地播放器特征信息，构建用于调用所述系统硬件平台的本地播放器的本地播放器调用接口包括：

确定与所述本地播放器特征信息相匹配的回调特征信息；

基于所述回调特征信息构建所述本地播放器调用接口，其中所述本地播放器调用接口用于以回调的方式来调用所述系统硬件平台的本地播放器。

3.根据权利要求2所述的方法，其中，所述基于所述回调特征信息构建所述本地播放器调用接口包括：

当所述本地播放器特征信息指示在所述系统硬件平台的本地播放器被调用之前需要进行预处理时，基于所述回调特征信息构建所述本地播放器调用接口，其中所述本地播放器调用接口用于在调用所述系统硬件平台的本地播放器之前预处理所述本地播放器。

4.根据权利要求1所述的方法，其中，所述播放操作信息包括播放状态信息和/或播放歌曲信息。

5.根据权利要求1所述的方法，其中，所述本地播放器调用接口包括以下中的一者或多者：本地播放器播放控制接口、本地播放器暂停播放控制接口以及本地播放器释放控制接口。

6.一种基于嵌入式Linux音频播放器的平台通用控制系统，所述系统包括：

指令获取程序模块，用于基于系统业务层，获取用户播放操作指令；

播放器控制接口层调用程序模块，用于基于与所述系统业务层通过相应接口对接的播放器控制接口层，确定与所述用户播放操作指令相对应的本地播放器调用接口，其中所述播放器控制接口层配置有多个与系统硬件平台的本地播放器相关联的本地播放器调用接口，其中，所述播放器控制接口层中的所述本地播放器调用接口和所述系统硬件平台的所述本地播放器通过以下方式进行关联：

获取所述系统硬件平台的本地播放器特征信息；所述本地播放器特征信息包括系统硬件平台标识信息和版本号；

基于所述本地播放器特征信息，构建用于调用所述系统硬件平台的本地播放器的本地播放器调用接口；

本地播放器调用程序模块，用于基于所确定的本地播放器调用接口，调用系统硬件平台的本地播放器执行相应的操作；

其中，所述系统还用于：

当所述用户播放操作指令用于指示播放器拓展功能时，确定与所述用户播放操作指令相对应的拓展播放接口，其中所述播放器控制接口层还配置有多个用于获取播放操作信息的拓展播放接口；

基于所确定的拓展播放接口，获取相应的播放操作信息；以及

将所述播放操作信息传递至所述系统业务层。

7.一种电子设备，其包括：至少一个处理器，以及与所述至少一个处理器通信连接的存储器，其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-5中任一项所述方法的步骤。

8.一种存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现权利要求1-5中任一项所述方法的步骤。

Images