先前捕捉的音频的检索机制的制作方法

文档序号:12469412阅读:150来源:国知局
先前捕捉的音频的检索机制的制作方法与工艺

技术领域

本发明的实施例涉及将来自环形缓冲器的过去的音频数据提供给与软件程序接口的系统侧音频处理输入/输出单元,以便将由硬件装置产生的过去的音频数据提供给该软件程序。其他实施例也被描述。



背景技术:

在计算机系统上执行的软件程序一般通过与该系统的音频硬件装置(例如,麦克风)相关联的装置驱动器程序(这些装置驱动器程序可以是软件程序正在其上执行的操作系统的一部分)与这些音频装置进行通信。例如,软件程序可以通过与麦克风的装置驱动器程序进行交互来访问麦克风产生的音频数据。环形缓冲器用于临时存储正在软件程序和装置驱动器程序之间传送的音频数据。当硬件装置(例如,麦克风)产生音频数据时,装置驱动器程序将音频数据写入到环形缓冲器中。软件程序估计在环形缓冲器中何时有预先布置的量的音频数据将可用,并且当它确定有该量的音频数据可用时,耗用来自环形缓冲器的音频数据。

一些计算机系统包括专用麦克风路径,该专用麦克风路径总是记录音频数据,因此持续地将音频数据写入到环形缓冲器中。专用麦克风路径对于检测用户的语音命令是有用的,而用户不必手动地启动语音命令应用、甚至不必“唤醒”装置。例如,在和装置中可用的“Hey Siri”特征利用专用麦克风路径来检测用户的语音命令,即使装置的各部分处于休眠模式或者被停用。



技术实现要素:

各种软件程序(诸如手持便携式装置上的语音命令应用)依赖于耗用由麦克风捕捉的音频。当用户按下按钮来启动语音命令应用时,语音命令应用可能花费一些时间(例如,数百毫秒)来配置装置的软件/硬件以接受用户的言语。当语音命令应用准备好接受用户的言语时,它可以用声音通知用户(例如,用铃声),或者通过装置的显示器上的视觉指示通知用户。然而,用户可能在语音命令应用向用户通知它准备好接受用户的言语之前开始向语音命令应用讲出语音命令。就这一点而论,起始(startup)时间延迟可能导致语音命令应用仅接收用户的言语的一部分(即,用户的言语的开头被切掉)。例如,用户可以通过按下按钮(或者通过讲出触发命令,诸如“Hey Siri”)来触发语音命令应用,然后立即开始讲出用户命令(例如,“导航到最近的加油站”)。由于起始时间延迟,语音命令应用可能不能接收到用户命令的第一个词,因此接收到不完整的用户命令(例如,“到最近的加油站”)。实施例利用总是进行记录的专用麦克风路径来使语音命令应用回到过去,并且访问在语音命令应用准备好接受用户的言语之前或者甚至在语音命令应用被触发之前捕捉的音频数据。

实施例允许在计算机系统上执行的软件程序(例如,客户端应用)耗用来自环形缓冲器的过去的音频数据。客户端应用可以发出不仅耗用实时音频数据、而且还耗用来自环形缓冲器的过去的音频数据的请求。客户端应用可以尽可能快地耗用过去的音频数据,直到它“赶上”实时为止。一旦客户端应用“赶上”实时,客户端应用然后就可以继续耗用实时音频数据。在一个实施例中,客户端应用与系统侧音频处理输入/输出(I/O)单元(SIO)接口以耗用来自环形缓冲器的过去的音频数据。SIO接收来自客户端应用的耗用过去的音频数据的请求,并且SIO通过将过去的音频数据提供给客户端应用来对该请求做出响应。

以上概要不包括本发明的所有方面的穷举列表。可以设想本发明包括以上概括的各方面的所有合适的组合、以及下面的具体实施方式中公开的并且在随本申请提交的权利要求中具体指出的那些。这样的组合可能具有在以上概要中未被明确记载的特定优点。

附图说明

在附图中以举例的方式、而非限制的方式例示说明本发明的实施例,在附图中,相似的附图标记指示类似的元件。应指出,在本公开中对“一”或“一个”实施例的论述不一定是对同一个实施例的论述,它们意指至少一个。此外,为了减少附图的总数,给定的图可以被用来例示说明本发明的多于一个的实施例的特征,结果,并非图中所有元件对于给定实施例都是必需的。

图1是例示说明根据一些实施例的使用环形缓冲器传送音频数据的音频输入/输出(I/O)系统的框图。

图2A是例示说明根据一些实施例的音频输入/输出(I/O)系统的框图,在该音频I/O系统中,SIO将来自环形缓冲器的过去的音频数据提供给客户端应用。

图2B是例示说明根据一些实施例的音频输入/输出(I/O)系统的框图,在该音频I/O系统中,SIO已经将过去的音频数据提供给客户端应用,并且已经赶上实时音频数据。

图3是例示说明根据一些实施例的允许将过去的音频数据提供给客户端应用的计算机系统的框图。

图4是例示说明根据一些实施例的允许将过去的音频数据提供给客户端应用的多处理器计算机系统的框图。

图5是例示说明根据一些实施例的手持便携式计算机系统(也被称为移动通信装置)的示图。

具体实施方式

现在参照附图来说明本发明的几个实施例。每当这里描述的实施例的各方面未被明确定义时,本发明的范围并非仅限于所示的部分,这些部分仅仅意在于例示说明的目的。此外,虽然阐述了许多细节,但是理解的是,本发明的一些实施例没有这些细节也可以实施。在其他情况下,没有详细示出公知的电路、结构和技术,以便不使该描述的理解模糊。

图1是例示说明根据一些实施例的使用环形缓冲器传送音频数据的音频输入/输出(I/O)系统的框图。音频I/O系统包括环形缓冲器130、客户端应用110、系统侧音频处理I/O单元(SIO)120、麦克风150以及装置侧音频处理I/O单元(DIO)140。音频I/O系统一般通过使用环形缓冲器130作为麦克风150捕捉的音频数据的汇聚点来将该音频数据传送到客户端应用110。SIO 120一般表示提供供客户端应用与硬件装置(诸如麦克风150)进行交互的接口的系统侧接口(例如,作为操作系统程序OS的一部分)。在一个实施例中,SIO 120提供供客户端应用110或其他软件程序与系统的硬件装置(例如,麦克风150)进行交互的应用程序设计接口(API)。客户端应用110可以调用SIO 120的例程,以使得客户端应用110可以耗用由麦克风150或能够产生/提供音频数据的其他硬件装置已经捕捉的音频数据。客户端应用110可以被一个或多个客户端线程执行。在一个实施例中,SIO 120是可从Cupertino,CA的Apple,Inc.得到的操作系统的核心音频框架中提供的音频硬件抽象层(音频HAL)。

DIO 140一般表示提供用于操作或控制硬件装置(诸如麦克风150)的接口的装置侧接口(例如,也作为OS的一部分)。DIO 140使得更高级程序能够访问硬件装置(例如,麦克风)的硬件功能,而无需知道这些硬件功能的细节。例如,上层程序可以与DIO 140接口以启动麦克风150并且拾取麦克风150捕捉的声音作为数字音频位流。在一个实施例中,DIO 140可以是硬件装置的装置驱动器。例如,DIO 140可以是麦克风装置驱动器。DIO 140通常是硬件装置相关的(即,每个硬件装置具有它自己的DIO 140),而且也是特定于给定操作系统(OS)的。DIO 140可以被一个或多个装置线程执行。在一个实施例中,装置线程中的一个或多个可以被直接存储器访问(“DMA”)协处理器执行,以将麦克风150捕捉的音频数据写入到环形缓冲器130中。

为了方便表达,软件组件(诸如SIO 120和DIO 140)被描述为执行操作,但是执行软件组件的处理器响应于执行软件组件的指令来执行操作。例如,陈述DIO 140将音频数据写入到环形缓冲器130中是一种方便的陈述计算机系统上的处理器(例如,CPU或DMA协处理器)执行DIO 140的软件指令以将音频数据写入到环形缓冲器130中的方式。

当麦克风150工作(即,捕捉音频)时,DIO 140将麦克风150捕捉的音频数据写入到环形缓冲器130中。DIO 140将音频数据写入到环形缓冲器130中的当前位置在本文中被称为“当前DIO位置”。当前DIO位置170在到达环形缓冲器130的末尾时环绕到环形缓冲器130的开头。

SIO 120从环形缓冲器130读取音频数据。SIO 120从环形缓冲器130读取音频数据的当前位置在本文中被称为“当前SIO位置”。当前SIO位置160在到达环形缓冲器130的末尾时环绕到环形缓冲器130的开头。为了从环形缓冲器130读取音频数据,SIO 120需要知道当前DIO位置170。然而,DIO 140持续地将当前DIO位置170传送到SIO 120是低效率的。因此,在一个实施例中,DIO 140周期性地产生可由SIO 120使用以估计或预测当前DIO位置170的信息。例如,每次当前DIO位置170从环形缓冲器130的末尾环绕到环形缓冲器130的开头时,DIO 140可以产生时间戳。SIO 120然后可以基于这样的时间戳的统计分析来估计当前DIO位置170。

如图1所示,SIO 120从环形缓冲器130在落后于估计的当前DIO位置170的位置处读取音频数据。这确保SIO 120不会读取还未被写入到环形缓冲器130中的音频数据。在一个实施例中,SIO 120在从环形缓冲器130读取音频数据之前或者之时在当前SIO位置160和估计的当前DIO位置170之间至少保持客户端侧偏移180,以确保SIO 120不会先于当前DIO位置170读取音频数据。客户端侧偏移180本质上是关于SIO 120可以从环形缓冲器130在估计的当前DIO位置170后面有多接近地读取音频数据的限制。SIO 120将正在耗用音频数据的客户端应用110的客户端线程置于休眠,直到SIO 120确定当前DIO位置170领先当前SIO位置160至少客户端侧偏移180为止。当SIO 120确定当前DIO位置170领先当前SIO位置160至少客户端侧偏移180时,SIO 120唤醒客户端线程以将音频数据(来自环形缓冲器130、在当前SIO位置160处)提供给客户端应用110。

在一个实施例中,SIO 120从环形缓冲器130读取预先布置的量的音频数据,所述预先布置的量的音频数据在本文中被称为缓冲单元。缓冲单元保存表示一段时间段期间的音频信号的音频数据。该时间段在本文中被称为缓冲单元的持续时间。如果缓冲单元保存10毫秒回放的音频数据,则缓冲单元的持续时间为10毫秒。如所示,每个缓冲单元用点线划界。在一个实施例中,每个客户端应用110可以根据需要指定缓冲单元的持续时间。

图2A是例示说明根据一些实施例的音频输入/输出(I/O)系统的框图,在该音频I/O系统中,SIO正在将来自环形缓冲器的过去的音频数据提供给客户端应用。如以上所讨论的,客户端应用110可以调用SIO 120的例程来耗用来自环形缓冲器130的由麦克风150产生的音频数据。SIO 120将客户端应用110的客户端线程置于休眠,直到它确定在环形缓冲器130中音频数据的缓冲单元可供客户端应用110耗用为止。当SIO 120确定在环形缓冲器130中音频数据的缓冲单元可用时,SIO 120唤醒客户端线程,并且将音频数据的缓冲单元提供给客户端应用110。SIO 120重复使客户端线程休眠和唤醒客户端线程的这个循环,以当在环形缓冲器130中音频数据可用时将音频数据提供给客户端应用110。这种提供音频数据的模式(其中,SIO 120周期性地唤醒客户端线程以当音频数据可用时从环形缓冲器130提供音频数据)在本文中被称为实时地提供音频数据。类似地,耗用以这种方式提供的音频数据的客户端应用110被说成是实时地耗用音频数据。

在一个实施例中,计算机系统实现专用麦克风路径,该专用麦克风路径总是记录音频数据,因此持续地将音频数据写入到环形缓冲器130中。就这一点而论,在客户端应用110调用SIO 120的例程以耗用麦克风150产生的音频数据时,先前被专用麦克风路径记录的音频数据可能已经存在于环形缓冲器130中。实施例允许客户端应用110耗用来自环形缓冲器130的此预先存在的音频数据。环形缓冲器130中的预先存在的音频数据在本文中将被称为过去的音频数据。在一个实施例中,SIO 120包括将过去的音频数据提供给请求过去的音频数据的客户端应用110的例程。客户端应用110可以调用SIO 120的这个例程来耗用麦克风150产生的过去的音频数据。在一个实施例中,客户端应用110对SIO 120的例程指定如下这样的时间值,该时间值指定从其开始耗用来自环形缓冲器130的音频数据的在过去的时间量。例如,客户端应用110可以指定指示它想要从过去的500毫秒开始耗用音频的时间值。SIO 120然后确定环形缓冲器130中的与从过去的500毫秒开始的音频数据对应的位置。SIO 120然后将当前SIO位置160设置为环形缓冲器130中的与指定的过去的时间对应的位置。SIO 120然后将音频数据提供给客户端应用110,该音频数据从这个位置开始并且随时间前进、直到赶上正被写入到环形缓冲器130中的实时数据为止。要指出,SIO 120无需执行实时提供音频数据所需的客户端线程的休眠和唤醒,因为过去的音频数据已经存在于环形缓冲器130中,因此客户端线程无需等待音频数据在环形缓冲器130中可用。就这一点而论,SIO 120可以尽可能快地将过去的音频提供给客户端应用110,直到赶上正被写入到环形缓冲器130中的实时音频数据为止。

在一个实施例中,客户端应用110可以调用SIO 120的例程来确定过去的音频数据是否可以被从环形缓冲器130访问。SIO 120可以用过去的音频数据是否可以被访问的指示来对(通过SIO 120的例程的调用从客户端应用110接收的)请求做出响应。在一个实施例中,客户端应用110可以调用SIO 120的例程来确定在环形缓冲器130中有多少的过去的音频数据可用。SIO 120可以用在环形缓冲器130中可用的过去的音频数据量来对(通过SIO 120的例程的调用从客户端应用110接收的)请求做出响应。

作为例子,结合图2A,考虑以上在发明内容部分中讨论的语音命令应用。用户在时间t=T1启动语音命令应用(VCA)。然而,由于起始时间延迟,VCA直到时间t=T2才准备好耗用来自环形缓冲器130的音频数据。就这一点而论,VCA从时间t=T2开始实时地耗用音频数据。然而,VCA不能耗用或以其他方式访问在时间t=T2之前存储在环形缓冲器130中的音频数据。实施例允许VCA耗用来自环形缓冲器130的此过去的音频数据(例如,通过如以上所讨论的那样调用SIO的例程),结果,VCA可以拾取用户在VCA准备好接受输入之前所讲的话语。

图2B是例示说明根据一些实施例的音频输入/输出(I/O)系统的框图,在该音频I/O系统中,SIO已经将过去的音频数据提供给客户端应用,并且已经赶上实时音频数据。在SIO 120将过去的音频数据提供给客户端应用110之后,SIO 120最终赶上正被写入到环形缓冲器130中的实时音频数据。在SIO 120将过去的音频数据提供给客户端应用110的时间期间,DIO 140可能已经将附加的音频数据写入到环形缓冲器130中。例如,在SIO 120正将过去的音频数据提供给客户端应用110的同时,DIO 140可能已经结束将音频数据写入到缓冲单元X中并且还将音频数据写入到缓冲单元X+1中。当客户端应用110首次调用SIO 120的例程来耗用过去的音频数据时,缓冲单元X没有准备好供客户端应用110耗用(参见示出缓冲单元X仅被部分加阴影的图2A)。然而,等到SIO 120结束将过去的音频数据提供给客户端应用110并且到达缓冲单元X的开头的时候,缓冲单元X现在可供耗用,并且被看作过去的音频数据。就这一点而论,SIO 120将缓冲单元X中的音频数据提供给客户端应用110,而不使客户端线程休眠或者以其他方式等待缓冲单元X中的音频数据可用,这是因为缓冲单元X中的音频数据现在是可用的。然而,当如图2B所描绘的,SIP已经赶上实时音频数据时,缓冲单元X+1还不可供耗用,因为当前DIO位置170不领先当前SIO 160位置至少客户端侧偏移180。因此,当SIO 120到达缓冲单元X+1的开头时,在它可以将缓冲单元X+1内的音频数据提供给客户端应用110之前,它需要等待。因此,从缓冲单元X+1开始向前前进,SIO 120实时地将音频数据提供给客户端应用110(例如,周期性地唤醒客户端线程以当音频数据可用时将音频数据提供给客户端应用110)。以这种方式,SIO 120将来自环形缓冲器的过去的音频数据提供给客户端应用110,并且还在提供过去的音频数据之后无缝地继续提供来自环形缓冲器130的实时音频数据。

图3是例示说明根据一些实施例的允许将过去的音频数据提供给客户端应用的计算机系统的框图。计算机系统300包括处理器310、环形缓冲器130以及麦克风150。处理器310可以是专用处理器(诸如专用集成电路(ASIC))、通用微处理器、现场可编程门阵列(FPGA)、数字信号控制器或一组硬件逻辑结构。处理器310执行软件执行堆栈320。软件执行堆栈320可以被划分为用户空间330和内核空间335。用户空间330包括客户端应用340A-C、音频数据处理堆栈350以及音频硬件抽象层(音频HAL)360。内核空间335包括麦克风装置驱动器370。环形缓冲器130也是内核空间335的一部分。为了例示说明,作为方便的示出软件执行堆栈320的各层被处理器310执行的方式,软件执行堆栈320及其各层被描绘为在处理器310的内部,然而它们不一定在处理器310内被实现或者它们的相关联的软件指令被存储在处理器310内。参见下面的例子,即,软件执行堆栈320的层可以如何在音频I/O系统的“分布式”实现中、在手持便携式系统(诸如智能电话)中运行的应用和OS之间、以及在车载资讯娱乐单元中运行的软件(包括虚拟机软件)之间划分的例子。

软件执行堆栈320的顶部是客户端应用340A-C。客户端应用340A-C可以是希望耗用麦克风150产生的音频数据的任何类型的软件程序。因此,客户端应用340A-C被认为是音频数据的耗用者。软件执行堆栈320的底部是与麦克风150接口的麦克风装置驱动器370。麦克风装置驱动器370是DIO 140的例子。就这一点而论,麦克风装置驱动器370可以实现本文描述的DIO 140的操作中的任何一个,包括控制麦克风150的操作。在一个实施例中,麦克风装置驱动器370负责将麦克风150捕捉的音频数据存储到环形缓冲器130中。在一个实施例中,麦克风150捕捉的音频数据在被存储在环形缓冲器130中之前被音频编解码器380处理。在一个实施例中,音频编解码器380包括将麦克风150捕捉的模拟音频信号转换为数字形式的模数转换器(ADC)。

客户端应用340A-C通过音频HAL 360与麦克风150接口。音频HAL 360为客户端应用340A-C或其他软件程序提供一致的、可预测的接口来与硬件装置(例如,麦克风150)进行交互。音频HAL 360是SIO 120的例子。就这一点而论,音频HAL 360可以实现本文描述的SIO 120的操作中的任何一个,包括与将过去的音频数据提供给客户端应用(例如,客户端应用110)相关的操作。在一个实施例中,音频HAL 360提供包括耗用过去的音频数据的例程的应用程序设计接口(API)。在一个实施例中,耗用过去的音频数据的例程包括指定从其开始耗用过去的音频数据的在过去的时间的输入参数。在一个实施例中,音频HAL API包括确定过去的音频数据是否可以被访问的例程。在一个实施例中,音频HAL API包括确定在环形缓冲器130中有多少过去的音频数据可用的例程。因此,客户端应用340A-C可以与音频HAL 360接口(例如,通过调用音频HAL的例程)以耗用来自环形缓冲器130的过去的音频数据。在一个实施例中,音频处理堆栈350在软件执行堆栈320中存在于客户端应用340A-C和音频HAL 360之间,以在音频HAL 360提供的音频数据被提供给客户端应用340A-C之前对音频数据进行处理。

图4是例示说明根据一些实施例的允许将过去的音频数据提供给客户端应用的多处理器计算机系统的框图。计算机系统400包括主处理器410A、辅助处理器410B、环形缓冲器130以及麦克风150。主处理器410A和辅助处理器410B可以是专用处理器(诸如专用集成电路(ASIC))、通用微处理器、现场可编程门阵列(FPGA)、数字信号控制器或一组硬件逻辑结构。

在一个实施例中,主处理器410A被配置为在计算机系统400处于“唤醒”模式时执行宽范围的任务,包括复杂的计算操作,诸如在计算机系统的显示器上渲染图形输出以及通过网络发送数据。相比之下,辅助处理器410B被配置为在装置处于节电模式或“休眠”模式时(例如,当计算机系统400处于暂停随机存取存储器(RAM)模式时,和/或当计算机系统400的主要视觉接口(诸如触摸屏或键盘)未被完全启动时,例如,当手持便携式计算机系统上的锁屏被开启时)执行范围相对有限的或少量的计算便宜的操作。这样的计算便宜的操作或有限范围的任务可以包括将麦克风150产生的音频数据写入到环形缓冲器130中。主处理器410A在完全工作时需要比辅助处理器410B多得多的总功率。主处理器410A本身可以通过例如基本上停止所有的计算操作来转变到节电模式,诸如被停用或休眠状态。将主处理器410A置于节电模式可以大幅减小计算机系统400的电源(例如,电池)的负担。在主处理器410A处于节电模式时,以及计算机系统400整体处于休眠模式时,辅助处理器410B可以保持完全发挥功能(即,被启动或被唤醒),用于持续地将麦克风150产生的音频数据写入到环形缓冲器130中。

主处理器410A执行软件执行堆栈420。软件执行堆栈420可以被划分为用户空间430和内核空间435。用户空间430包括客户端应用440A-C、音频数据处理堆栈450以及音频硬件抽象层(音频HAL)460。内核空间435包括控制辅助处理器的操作的辅助处理器装置驱动器465。

在一个实施例中,辅助处理器410B包括麦克风装置驱动器470。麦克风装置驱动器470实现与参照图3描述的麦克风装置驱动器370类似的功能。例如,麦克风装置驱动器470可以负责将麦克风150捕捉的音频数据存储到环形缓冲器130中。在一个实施例中,麦克风150捕捉的音频数据在被存储在环形缓冲器130中之前被音频编解码器480处理。在一个实施例中,麦克风装置驱动器470在内核空间中被执行,并且环形缓冲器130是内核空间的一部分。

辅助处理器410B被配置为通过在主处理器被停用时保持启动而作为主处理器410A的补充。辅助处理器410B可通过任何方式的组合来实现这一点。例如,辅助处理器410B可以被持久地启动(例如,“总是开启”),或者它可以响应于主处理器410A被停用而被启动。因此,辅助处理器410B可以执行麦克风装置驱动器470来将麦克风150捕捉的音频数据存储到环形缓冲器130中,即使主处理器410A被停用或者处于节电模式(例如,休眠模式)。这允许客户端应用440A-C在主处理器410A处于节电模式时耗用捕捉的过去的音频数据。

音频HAL 460与辅助处理器装置驱动器465接口以从环形缓冲器130获得音频数据。尽管在附图中描绘了单个辅助处理器410B,但是计算机系统400的其他实施例可以包括多于一个的辅助处理器410B。音频HAL 460可以实现本文描述的SIO 120的操作中的任何一个,包括与将过去的音频数据提供给客户端应用440A-C相关的操作。因此,客户端应用440A-C可以与音频HAL 460接口(例如,通过调用音频HAL的例程)以耗用来自环形缓冲器130的过去的音频数据。

图5是例示说明根据一些实施例的手持便携式计算机系统(也被称为移动通信装置,或简称为手持便携装置)的示图。手持便携式计算机系统500包括常见于这样的装置中的若干个组件。这里,手持便携式计算机系统500包括显示器510、扬声器520A和520B、按钮530以及内置麦克风540。附加的麦克风可以集成在手持便携式计算机系统500中。在一个实施例中,外部麦克风可以例如经由耳机耦合到手持便携式计算机系统500。根据本文描述的实施例,手持便携式计算机系统500可以为在手持便携式计算机系统500内运行的客户端应用或其他软件程序提供耗用麦克风540捕捉的过去的音频数据的能力。

各种软件程序可以受益于耗用过去的音频数据的能力。例如,如以上所讨论的,该特征适用于语音命令应用,诸如可从Cupertino,CA的Apple,Inc.获得的装置上的程序。很多时候,当用户启动语音命令应用时,用户在语音命令应用准备好接受输入(例如,语音命令应用通常通过播放音效来向用户通知它准备好接受输入)之前开始讲话,这导致语音命令应用仅接收到用户的言语的一部分。耗用过去的音频数据(例如,来自持续地将音频数据写入到环形缓冲器中的专用麦克风路径)的能力将允许语音命令应用拾取在语音命令应用准备好接受输入之前、甚至在用户启动语音命令应用之前所讲的话语,从而给予用户语音命令应用可以即刻接受用户的言语(即,用户一启动语音命令应用,就可以接受用户的言语)的表现。

可以受益于耗用过去的音频数据的能力的其他类型的软件程序是音乐辨识应用,诸如可从英国伦敦的Shazam获得的Shazam。很多时候,当用户听到他们希望识别的歌曲时,用户争相打开他们的音乐辨识应用,但是等到该应用被打开时,该歌曲已经结束,或者该歌曲不再可听。就这一点而论,用户错失了识别该歌曲的机会。耗用过去的音频数据的能力将允许音乐辨识应用回到过去收听当时正在播放的歌曲,并且为用户识别该歌曲。

应指出,这里提及的应用是作为例子、而非限制而提供的。除了这里提及的应用之外的其他类型的应用也可以利用耗用过去的音频数据的能力来实现各种有用的功能。

此外,图1中所示的音频I/O系统的框图不仅仅可以在如图5中所示的手持便携装置中实现,其中,在该情况下,图1中所描绘的所有的软件或硬件组件都可以驻留在智能电话或平板计算机的单个壳体内;音频I/O系统也可以以“分布式”的方式实现。例如,考虑手持便携装置(诸如智能电话)经由有线连接(例如,根据通用串行总线USB规范)或无线连接(例如,根据蓝牙规范)通信地链接到车载资讯娱乐单元的情况。在该情况下,DIO 140和环形缓冲器130可以是在车载资讯娱乐单元的本机OS的顶部运行的虚拟机的一部分,而客户端应用110和SIO 120在手持便携装置中运行。在这样的分布式音频I/O系统中存在上述(客户端应用110)对过去的音频数据的请求可以被触发的几种情况。这些包括i)用户按下智能电话上的菜单按钮,ii)用户按下车辆的其他物理接口或方向盘上的按钮,这使虚拟机用信号告知智能电话(因此通知客户端应用110),以及iii)语音辨识软件在车载资讯娱乐中心中(例如,在虚拟机的顶部)运行,该语音辨识软件识别来自车辆的麦克风的信号内的触发短语,例如,“Hey Siri”,并且作为响应,用信号告知智能电话(因此通知客户端应用110)。在所有的这样的情况下,音频I/O系统有效地具有“总是收听的麦克风”,因为车辆麦克风捕捉的音频数据持续地被DIO 140写入到环形缓冲器130中,但是没有被流传输到智能电话。一旦客户端应用110生成对过去的音频数据的请求,SIO 120就如以上结合图1、图2A、图2B描述的那样管理从环形缓冲器130对音频数据的读取,除了它是通过智能电话和在车载咨询娱乐单元中运行的虚拟机之间的现存的有线或无线连接这样做之外。

实施例可以是制造品,在该制造品中,机器可读存储介质上存储将一个或多个数据处理组件(这里通称为“处理器”)配置为执行上述操作的指令。机器可读存储介质的例子包括只读存储器、随机存取存储器、CD-ROM、DVD、磁带以及光学数据存储装置。机器可读存储介质也可以分布在网络上以使得软件指令被以分布式的方式存储和执行。在其他实施例中,这些操作中的一些可以由包含硬连线逻辑的特定硬件组件执行。这些操作可替代地可以由编程的数据处理组件和固定硬连线电路组件的任何组合执行。

虽然已经描述了并且在附图中示出了某些实施例,但是要理解,这样的实施例仅仅例示说明、而非限制广泛的发明,并且本发明不限于所示出的和所描述的特定构造和布置,这是因为本领域的普通技术人员可想到各种其他变型。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1