CN117542343A - 文本语音转换的方法和装置 - Google Patents

Abstract

根据本公开的实施例，提供了文本语音转换的方法和装置。该方法包括将文本发送至远程设备以进行文本语音转换；存储从所述远程设备接收到的与所述文本对应的语音；以及在未来的播放点开始播放所述语音，所述播放点基于与所述文本相关联的元数据而确定。这种文本语音转换的方法能够保证提前完成在线文本语音转换，提高语音播放事件的播放质量的同时提了高用户体验。

Description

文本语音转换的方法和装置

技术领域

本公开的示例实施例总体涉及文本语音转换领域，特别地涉及文本语音转换的方法和装置。

背景技术

文本语音转换(Text-To-Speech，TTS)是将文本转换成语音，从而用于语音辅助技术中的一种技术。文本语音转换用途很广，包括诸如短信息、电子邮件等各种文本信息的阅读、导航系统中导航信息的语音播报等等。

文本语音转换所用的关键技术就是语音合成。目前的语音合成技术通常用算法实现，主要包括文本分析、语音合成以及韵律处理等几部分。要合成出高质量的语音，所采用的算法是极为复杂的，因此对机器的要求也非常高。

通常，以车载导航系统进行语音播报为例，由于车辆的处理设备计算能力较差，只能采用一些较为基础的文本语音转换算法来进行文本信息到语音播报的转换，从而造成车辆自带的处理设备所输出的语音往往比较生硬且机械，让人听起来很不舒服。为了改善这种情况，有的解决方案是将文本语音转换的操作放到计算能力较强的服务器上来完成，从而使语音播报更加顺畅和自然。

发明内容

在本公开的第一方面，提供了一种文本语音转换的方法。所述方法包括将文本发送至远程设备以进行文本语音转换；存储从所述远程设备接收到的与所述文本对应的语音；以及在未来的播放点开始播放所述语音，所述播放点基于与所述文本相关联的元数据而确定。

在根据本公开的实施例中，将所述文本发送至所述远程设备包括：响应于接收到激活语音播报事件的请求，根据所述语音播报事件确定将要通过语音播放的多条文本以及相关联的所述元数据；以及将所述多条文本中的至少部分文本发送至所述远程设备。

在一些实施例中，所述播放点表示时间或者位置。

在一些实施例中，所述文本发送至所述远程设备包括：基于可用于存储语音数据的本地存储容量，来确定向所述远程设备发送的文本的量。

在一些实施例中，将所述文本发送至所述远程设备包括：确定所述文本被转换为所述语音所需的预计处理时长；响应于到达所述播放点所需的预计等待时长超过所述预计处理时长并且二者之差在预定范围内，将所述文本传输至所述远程设备。

在一些实施例中，确定所述预计处理时长包括：基于单个的文本语音转换所需的平均时长和所述文本中包含的字数，来确定针对所述文本的所述预计处理时长。

在一些实施例中，确定所述预计处理时长包括：确定与所述远程设备之间的通信状况；确定所述文本和所述语音的数据量；根据所述数据量和所述通信状况来确定所述预计处理时长。

在一些实施例中，确定所述等待时长包括：获取当前移动速度；基于所述当前移动速度以及与所述播放点对应的位置，来确定所述预计等待时长。

根据本公开实施例的第二方面，提供了一种文本语音转换的装置。该装置包括：发送模块，被配置为将文本发送至远程设备以进行文本语音转换；接收存储模块，被配置为存储从所述远程设备接收到的与所述文本对应的语音；以及播放模块，被配置为在未来的播放点开始播放所述语音，所述播放点基于与所述文本相关联的元数据而确定。

在本公开的第三方面，提供了一种电子设备。该设备包括至少一个处理单元；以及至少一个存储器，至少一个存储器被耦合到至少一个处理单元并且存储用于由至少一个处理单元执行的指令。指令在由至少一个处理单元执行时使设备执行第一方面的方法。

在本公开的第四方面，提供了一种计算机可读存储介质。该计算机可读存储介质上存储有计算机程序，计算机程序可由处理器执行以实现第一方面的方法。

在本公开的第五方面，提供了一种计算机程序产品。该计算机程序产品包括计算机可执行指令，计算机可执行指令在被处理器执行时实现第一方面的方法。

应当理解，本发明内容部分中所描述的内容并非旨在限定本公开的实施例的关键特征或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的描述而变得容易理解。

附图说明

结合附图并参考以下详细说明，本公开各实施例的上述和其他特征、优点及方面将变得更加明显。在附图中，相同或相似的附图标记表示相同或相似的元素，其中：

图1示出了本公开的实施例能够在其中实现的示例环境的示意图；

图2示出了根据本公开的一些实施例的文本语音转换的过程的流程图；

图3示出了根据本公开的一些实施例的文本语音转换的过程的示意图；

图4示出了根据本公开的一些实施例的文本语音转换的装置的框图；以及

图5示出了能够实施本公开的多个实施例的设备的框图。

具体实施方式

下面将参照附图更详细地描述本公开的优选实施例。虽然附图中显示了本公开的优选实施例，然而应该理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

在本文中使用的术语“包括”及其变形表示开放性包括，即“包括但不限于”。除非特别申明，术语“或”表示“和/或”。术语“基于”表示“至少部分地基于”。术语“一个示例实施例”和“一个实施例”表示“至少一个示例实施例”。术语“另一实施例”表示“至少一个另外的实施例”。术语“第一”、“第二”等等可以指代不同的或相同的对象。

文本语音转换是一种用于将文本转换为可听语音的技术，目前其广泛应用于人机交互、文本信息播报、导航信息播报等等各种场景中。例如，文本语音转换可以应用于诸如手机、音箱、平板电脑等各种智能电子设备以及车辆中。以车辆，文本语音转换技术能够将导航信息、各种文本信息以语音的方式进行播报，而使用户(如司机)更多地精力集中在前方的道路，从而提高驾驶的安全性。

如前文中所提到的，文本语音转换的质量往往取决于执行文本语音转换的电子设备的计算能力。由于考虑到稳定性等因素，车辆中往往采用稳定性较高但计算能力较差的处理器，从而导致文本语音转换只能采用较为基础和简单的算法。在这种情况下，如果采用车辆的处理器进行文本语音转换来实现语音播报，得到的语音质量往往较差，从而影响到了用户体验。

随着移动互联网计算的不断发展，为了解决这个问题，有的解决方案是在需要进行文本语音转换时，将文本语音转换操作交由计算能力较强的服务器的处理器来执行。具体而言，在需要进行文本语音播报时，车辆的处理器会将所要语音播报的文本上传至服务器。由服务器使用其较强的计算能力进行高质量的文本语音转换后再下载至车辆，并由车辆进行播报，从而使得语音播报更加顺畅和自然。

然而，这种解决方案依赖于移动互联网环境。在车辆行驶过程中，受基站天线与环境的影响(例如在车辆通过隧道，山区等环境时)，网络传输质量时好时差，导致使用服务器进行文本语音转换的处理在很多时候无法及时完成。

对于地图导航而言，有时会由于通信状况较差等因素而导致文本无法上传至云端服务器或者无法从云端服务器下载转换好的语音数据，进而导致语音播报无法及时完成，将是比较严重的问题，因为这可能会导致用户错过路口或者其他需要转换道路的重要节点。为了解决这个问题，目前的解决方案是当在线文本语音转换处理超时的情况下，切换为使用本地(即，车辆的处理器)来进行文本语音转换。这样一来，如前文中提到的，由于本地文本语音转换所使用的处理器计算能力交叉，处理算法也与服务器文本语音转换处理算法存在较大差别，导致所输出的语音也会存在较大差别。这些情况都影响到了用户在使用导航服务的体验。

当然，上文中只是以车辆导航服务为例阐述了在线文本语音转换操作可能存在的一些问题。由于目前文本语音转换服务应用广泛，在其他应用领域也可能会存在类似的问题。例如，当用户使用语音播报的方式听小说或者听新闻时，可能会存在类似的问题。下文中将主要以车载导航系统为例来描述本公开的构思。通过采用根据本公开的发明构思，能够解决或者至少部分地解决传统的在线文本语音转换服务所存在的上述问题或者其他潜在问题。应当理解的是，本公开的构思除了可以应用于车载导航的场景，还可以应用于使用在线文本语音转换的其他类似的场景，在下文中将不再分别赘述。

根据本公开的实施例提供了一种文本语音转换的方法以及相关的电子设备。根据本公开实施例的电子设备包括能够实施文本语音转换的方法的任意适当的电子设备，包括但不限于：车辆的包括诸如处理单元910或微控制器等的车机系统、手机、平板电脑、智能音箱、智能电视等等。以电子设备为车辆的车机系统为例，图1示出了根据本公开实施例的电子设备实施文本语音转换的方法的场景示意图。此外，电子设备除了处理单元910外，还包括存储器920。存储器920和处理单元910耦合，并且能够存储指令。指令能够在处理单元910执行时使得处理单元910执行根据本公开实施例的方法。存储器920除了可以存储指令外，还可以用来存储待上传至远程设备100的文本数据和/或从远程设备100下载的语音数据。当然，应当理解的是，用来存储指令的存储器和用来存储文本数据和/或语音数据的存储器可以是同一个存储器，也可以是不同的存储器，本公开对此并不做限制。

从图中可以看出，根据本公开实施例的电子设备能够以任意适当的方式与远程设备100进行通信以传输数据。远程设备100可以是前文中所提到的云端服务器，其处理器的计算能力高于根据本公开实施例的电子设备的处理单元910的计算能力，并由此能够进行更加复杂且智能化的算法来进行文本语音转换处理，使得转换后的语音更加自然和顺畅。应当理解的是，在一些替代的实施例中，远程设备100也可以是能够与根据本公开实施例的电子设备进行数据通信并具有更强计算能力的任意其他适当的电子设备，包括但不限于：手机、平板电脑等等。下文中将主要以远程设备100为云端服务器为例来描述根据本公开的发明构思。应当理解的是，其他情况也是类似的，在下文中将不再分别赘述。

此外，根据本公开实施例的电子设备和远程设备100可以采用任意适当的途径进行数据通信，这些适当的途径可以包括但不限于：无线局域网(WLAN)通信技术、蜂窝网络通信技术、蓝牙(Blue-tooth，BT)通信技术、近场通信(Near Field Communication，NFC)技术等等。下文中将主要以电子设备和远程设备100通过蜂窝网络通信技术为例来描述根据本公开的构思。应当理解的是，其他情况也是类似的，在下文中将不再分别赘述。

图2示出了根据本公开实施例的方法的流程的示意图。如前文中所提到的，该方法可以由电子设备的处理单元910执行指令的方式来执行。在框510中，处理单元910会将文本发送至远程设备100以进行文本语音转换。处理单元910获取或者确定将要发送至远程设备100的文本的方式将在下文中进一步阐述。远程设备100在获取到由车辆的处理单元910所发送的文本后，会对文本进行文本语音转换操作，从而得到与文本所对应的更为自然且顺畅的语音数据。之后，在框520，电子设备会从远程设备100下载由远程设备100转换好的语音数据并将其存储在存储器920中。

在一些实施例中，远程设备100可以将转换好的语音数据直接传输至电子设备以获得更好的语音播报质量。当然，在更多的实施例中，为了减少数据的传输量，远程设备100也可以先对转换好的语音数据进行压缩编码处理后再发送至电子设备。远程设备100可以采用任意适当的压缩编码技术来对转换好的语音数据进行压缩编码，并尽可能地减少压缩编码处理对语音质量产生的影响。以此方式，能够在基本不影响播放质量的情况下节约大量的网络带宽，从而节省了用户流量的同时还减小了传输时间，从而获得更好的用户体验。

在电子设备的存储器920存储了由远程设备100所转换的语音数据后，在框530，电子设备会使得播放设备在未来的播放点开始播放语音。播放点是基于与文本关联的元数据来确定的。一方面，本文中所提到的播放点可以表示时间或者位置。也就是说，在一些实施例中，播放点可以是指文本将要以语音形式播放的时间点或者位置点。

例如，在一些实施例中，用户对电子设备发送了在预定时间播放提醒语音信息或者阅读新闻或小说等的指令。在收到该指令的情况下，电子设备可以提前一定时间将需要以语音形式输出的文本(例如，包括提醒信息、新闻文本或小说文本)发送至远程设备100。远程设备100对文本进行文本语音转换并压缩编码后传输至电子设备。电子设备会将该语音数据存储至存储器920，以在与文本所关联的未来时间点播放与该文本对应的语音数据。

在一些实施例中，播放点也可以表示位置。例如，在车载导航的场景下，当用户开启导航后，电子设备会将导航过程中需要用语音提示的文本提前发送至远程设备100。远程设备100在进行文本语音转换后发送至电子设备并由电子设备来存储。当到达与文本相关联的预定位置时，电子设备会播放与该文本对应的语音，从而为用户提供导航服务。

以此方式，通过将文本信息以及对应的语音数据关联至播放点并提前进行转换的下载，即使在途经路段具有通信状况从而影响传输的情况，也能够使用提前存储好的语音数据在相关联的播放点进行播放。也就是说，根据本公开实施例的方法减小了在线文本语音转换对网络的依赖，通过将文本信息以及对应的语音数据关联至播放点并根据需要提前转换和传输，能够确保在任何情况下都能使用由远程设备100转换后的语音数据在预定的播放点进行播报。以此方式，不管网络状况如何，都能够使用户听到的播报语音更加顺畅和自然，提高了文本语音转换可靠性的同时也提高了用户体验。

本文中所提到的语音播报事件可以是指需要进行文本语音转换以进行语音播报的任意适当的事件，例如包括但不限于：语音导航播报、新闻、小说语音播放、机器人语音播报等等。下文中将以车载语音导航播报为例来描述本公开的构思。应当理解的是，本公开的构思应用于其他场景的情况也是类似的，在下文中将不再分别赘述。

在一些实施例中，处理单元910响应于接收到用户激活语音播放事件的请求，来根据语音播报事件来确定将要以语音播报的多条文本以及相关联的元数据。例如，当用户开启导航后(相当于激活了语音播放事件)，导航系统会进行处理以至少得到导航路径所涉及的关键位置(例如要转弯的路口等)以及对应的播报文本。除此之外，在一些实施例中，语音播报事件还可能包括在指定时间或者位置提示超速信息、提醒驾驶时间过长等文本信息。每个播报点可以对应一条或者多条文本。这些要播报的文本数据都会有对应的播放点相关联，元数据能够指示并提供这种要播放的文本以及对应的播放点的关联信息，从而使得要播放的与文本对应的语音数据能够在对应的播放点进行播放。

对于语音播报事件是新闻、小说语音播报的情况而言，新闻或小说文本中的每一句文本或者每一段文本可以作为一条文本。例如，在一些实施例中，处理单元910可以根据文本中的标点符号等数据来将要语音播报的文本分隔成多条文本。

然后，处理单元910会将所获取的多条文本中的至少部分文本发送至远程设备100。例如，在一些实施例中，处理单元910可以在确定多条文本后立即将这些文本逐条依次发送至远程设备100，远程设备100在对所接收到的多条文本依次进行转换并压缩编码后发送回电子设备。电子设备对接收的语音数据进行存储。

在所包含的文本的量比较大(例如，所涉及的文本的条数较多)，从而语音数据也比较大的情况下，这种情况可能会占用比较大的存储空间。然而，在有些实施例中，车辆的存储器920的可用容量可能有限，从而导致可能无法存储全部文本所对应的语音数据。考虑到这种情况，在一些实施例中，处理单元910会基于可用于存储语音数据的本地存储容量，来确定向远程设备100发送的文本的量。具体而言，处理单元910会首先确定用于存储语音的本地存储器920的可用容量，并根据可用容量来获取要发送至远程设备100的多条文本中的在至少部分文本。例如，在一些实施例中，语音播报事件可能包括上百条文本。处理单元910通过获取存储器920的可用容量，确定可用容量只能用于存储其中的50条文本所对应的语音数据。在这种情况下，处理单元910可以依照这些文本所关联的播放点的顺序，先依次将这上百条文本中的前50条文本上传至远程设备100进行文本语音转换。

处理单元910会控制播放设备对这些已存储的语音在预定的播放点进行播报，并将已经播放完毕的语音从存储器920中删除或移除。以此方式，处理单元910就可以进一步依据存储器920的可用容量来将后续的文本发送至远程设备100进行文本语音转换。此外，处理单元910可以根据每条文本所对应的文字的数目来估计所转换的语音的数据量。例如，在一些实施例中，可以根据经验数据来确定文本中的单字所对应的语音的数据量。以此方式，在确定文本的字数后，就能够根据字数以及每个单字所对应的语音的数据量来估计文本信息所占用的空间，具体方式将在下文中做进一步阐述。以此方式，处理单元910可以根据存储器920可用的空间以及所估计的文本信息所占用的空间，来确定要提前发送至远程设备100进行文本语音转换的至少部分文本。在这些文本对应的语音被播放并从存储器920删除后，处理单元910还可以提前将余下的其余文本发送至远程设备100进行文本语音转换。

在一些替代的实施例中，处理单元910也可以获取到语音播放事件所涉及的多条文本后立即将全部文本都发送至远程设备100，而先不管存储器920是否有可用容量来容纳这些全部文本所对应的语音数据。处理单元910随后会逐条下载这些文本所对应的语音数据并将其存储在存储器920中。当检测到存储空间不足以存储后续的语音数据时，处理单元910可以暂停下载并等待之前下载并存储的语音数据播报完毕并删除后再下载后续语音数据。当然，如果在存储器920容量足够的情况下，也可以将所需的全部语音数据逐条下载并存储到存储器920中，并在未来对应的播放点进行的语音播放。

以此方式，能够在适当的时机(例如网络信号较好时)就提前将需要语音播报的文本上传远程设备100，并完成从远程设备100的语音数据下载。此外，如前文中所提到的，由于文本与对应的播放点相关联，由此可以保证在到达播放点时播放语音数据。在这种情况下，由于不需要切换到本地进行文本语音转换处理，所播放的声音不会有明显变化，都能够保持自然且顺畅的状态，由此改善了用户体验。此外，尽管语音数据会占用较多内存，但由于在远程设备100侧使用适当的压缩编码技术对转换好的语音数据进行了压缩编码，可以减少内存占用以及下载所需的网络流量和时间。此外，处理单元910还可以根据存储器920的剩余空间大小，暂停后续文本上传和/或语音数据下载，从而减少对内存的过度占用并由此提高电子设备的稳定性和可靠性。

在一些实施例中，处理单元910还可以通过自适应的方式提前上传文本并下载对应的语音数据。具体而言，在一些实施例中，处理单元910会确定文本要转换为语音所需的预计处理时长。对于每一条文本而言，如图3所示，进行文本语音转换所需的预计处理时长可以包括该文本上传至远程设备100所需的时长T1、远程设备100对文本进行文本语音转换并且压缩编码所需的时长T2和从远程设备100获取对应的语音数据所需的时长T3。时长T1和T3都会依赖于电子设备和远程设备100之间的通信状况。在一些实施例中，通信状况可以包括网络延时和网络连接速度等。时长T2依赖于远程设备100的处理单元910的计算能力以及文本所对应的字数。在文本所对应的字数确定的情况下，时长T2是可以通过经验数据进行估计得出。

对于时长T1和T3的估计，在一些实施例中，处理单元910会确定电子设备所处的位置的网络延时和网络连接速度。网络延时和网络连接速度可以通过任意适当的手段来确定。例如，在一些实施例中，处理单元910可以利用ping工具来测试网络延时和网络连接速度。ping也被称为latency或jitter。它使用串流技术，用对应的服务器测试网络连接质量。

当然，应当理解的是，利用ping工具确定通信状况的实施例只是示意性的，并不旨在限制本公开的保护范围。其他任意适当的工具或者手段也是可能的，例如，在一些替代的实施例中，也可以使用iperf工具来确定当前的网络延时和网络连接速度。iperf是一个网络性能测试工具，其可以测试TCP和UDP带宽质量。可以测试最大TCP带宽，具有多种参数和UDP特征，并且可以给出带宽、延迟抖动和数据包丢失等数据。

当然，应当理解的是，诸如网络延时和网络连接速度等通信状况可以使用特定的线程以预定时间(例如100ms)间隔的方式来持续获取。处理单元910也可以对预定时间段内多次获取的网络延时和网络连接速度等数据分别取平均值，来作为该预定时间段内的通信状况数据。当然，在一些实施例中，处理单元910也可以使用所确定的最新的通信状况数据来确定预计处理时长。

在确定通信状况数据之后或者同时，处理单元910可以确定将要播报的至少一条文本的上传数据量以及与之对应的语音的下载数据量。上传数据量即为将文本上传至远程设备100的数据量。该数据量除了包括文本本身所对应的数据量之外，还可以包括相关联的元数据以及传输协议所需要的信息所占用的数据量或空间。下载数据量即为将语音下载至电子设备所对应的数据量。类似于上传数据量，其除了包括语音本身所对应的数据量之外，还可以包括相关联的元数据以及传输协议所需要的信息所占用的数据量或空间。

在一些实施例中，上传数据量和下载数据量都可以通过文本所对应的字数来确定。具体而言，可以通过经验或者运算等方式来确定每个字对应的上传数据量以及与之对应的语音的下载数据量。通过确定文本的字数以及每个字所对应的上传数据量和下载数据量，就可以估计该文本所对应的上传数据量和下载数据量。

在至少一条文本的上传数据量和通信状况等信息确定后，就可以根据这些数据来确定将文本传输至远程设备100所需要的时长T1。例如，T1可以根据网络延时和上传数据量与网络传输速度(上传速度)的比值来确定。类似地，由远程设备100所转换的与文本对应的语音数据从远程设备100传输至电子设备的时长T3可以根据下载数据量和通信状况。例如，T3可以根据网络延时和下载数据量与网络传输速度(下载速度)的比值来确定。远程设备100对文本进行文本语音转换并且压缩编码所需的时长T2则可以根据远程设备100对每个单字进行文本语音转换并且压缩编码所需的平均时长和文本所对应的字数来确定。在T1、T2和T3都确定后，就可以确定对文本进行文本语音转换所需的预计处理时长。

当然，应当理解的是，通过上面这种方式获取预计处理时长的实施例只是示意性的，并不旨在限制本公开的保护范围。其他任意适当的方式也是可能的。例如，在一些替代的实施例中，也可以根据之前所确定的每个单字所对应的预计处理时长以及文本所对应的字数来估计预计处理时长。这种方式所获取的预计处理时长更加简单，从而能够以更加快速且可控的方式进行文本的提前上传和语音的下载。

具体而言，在一些实施例中，处理单元910可以根据在通常情况下进行文本语音转换所需的总时长以及根据文本转换的字数，来确定在大多数情况下单个字在进行文本语音转换时的平均时长。该平均时长可以包括每个单字所对应文本的上传平均时长，语音数据的下载平均时长和文本语音转换平均时长。该单个字的平均时长被存储在存储器920中以供处理单元910获取或调用。在需要估算某段文字的预计处理时长时，只需要从存储器920获取该单个字的平均时长以及该段文字所涉及的总字数来估计这段文字可能需要的预计处理时长。这种方式能够进一步降低电子设备的处理单元910的负荷，从而提高电子设备的稳定性。

在确定预计处理时长之后或者与之同时，处理单元910会根据文本所要播放的播放点确定从当前时间点到播放点所需的预计等待时长。例如，在一些实施例中，在新闻或小说语音播报的场景下，处理单元910可以确定当前正在进行语音播放的文本大约在1分钟后播放完毕。此时，1分钟即为预计等待时长。

对于车载导航语音播报的场景，处理单元910可以通过电子设备的移动速度以及播放点中的对应的位置信息来去确定预计等待时长。例如，文本所对应的播放点所表示的位置指示该播放点距离当前地点还具有两公里的距离。根据该距离以及当前移动速度，来估计到达播放点所需的预计等待时长。当然，在一些实施例中，该当前移动速度也可以是预定时间段内的平均速度。在一些替代的实施例中，处理单元910也可以根据电子设备所处于的位置的预定范围内的所有同向车辆的平均速度作为该当前移动速度。以此方式，可以更加精准地估计等待时长。

在文本所对应的预计等待时长和前文中所提到的预计处理时长确定后，处理单元910会比较该预计等待时长和预计处理时长。如果预计等待时长等于或大于预计处理时长，并且预计等待时长与所述预计处理时长的差值在预定范围内，则将该文本传输至所述远程设备100。该预定范围可以是预先确定的范围，例如10秒～30秒或其他任意适当的时间范围。在一些替代的实施例中，该预定范围也可以根据通信状况等因素来调整。例如，在通信状况较好的情况(例如，网络延时小于某一延时阈值并且网络速度大于某一速度阈值)下，可以将预定范围设置为较小的值，例如10秒～20秒，而在通信状况较差的情况下，可以将预定范围设置为较大的值，例如20秒～60秒等等。以此方式，可以确保在通信状况的情况下能够完成语音数据的转换和下载，来由此提高电子设备的可靠性。

例如，对于新闻或小说语音播报的场景，所确定的预计等待时间(如当前正在播放的文本播放完毕所需的施加)为1分钟，并且所确定的将要语音播放的文本的预计处理时长为45秒中。通过比较预计等待时间和预计处理时长，两者差值为15秒，满足预计等待时长大于预计处理时长，并且预计等待时长与所述预计处理时长的差值在预定范围内的条件，此时电子设备会根据上文中所描述的上传对应的文本至远程设备100并直至完成语音数据的下载。

对于车载导航语音播报的场景，也可以通过上述类似的方法来提前进行文本的在线文本语音处理。当然，在一些替代的实施例中，在导航场景并且移动速度确定的情况下，该预计等待时长和预计处理时长也可以以距离的方式来体现。例如，在一些实施例中，处理单元910可以根据所获取的移动速度以及之前所提到的预计处理时长来确定电子设备可能在预计处理时长下所移动的距离L。如果从电子设备的当前位置到文本所对应的播放点表示的位置的距离大于等于该距离L，并且两者的差值在预定的范围内，则处理单元910可以发送该文本到远程设备100，并在远程设备100转换成语音并压缩编码后传输至电子设备。以此方式，在抵达播报点前，就已经完成了对应文本的在线文本语音转换处理。因此，可以保证抵达播报点时，准时播报对应的文本。

以此方式，可以根据通信状况，以自适应的方式提前完成在线文本语音转换处理，保证转换后的语音准时播放。此外，类似于之前提到的情况，由于不需要切换到本地文本语音转换处理，播报的声音都能够保持自然且顺畅的状态而不会有变化，从而提高了用户体验。另外，虽然需要将在线文本语音转换处理后的语音数据存储到存储器中，但因为只存储即将播报的语音数据，减少了空间占用的同时提高了电子设备的稳定性。

图4示出了根据本公开的某些实施例的需要进行语音信息播放的装置800的示意性结构框图。根据本公开实施例的装置800可以被实现为或者被包括在前文所提到的电子设备中。装置800中的各个模块/组件可以由硬件、软件、固件或者它们的任意组合来实现。

如图所示，装置800包括发送模块810，被配置为将前文中所提到的文本发送至远程设备100以进行文本语音转换。装置800还包括接收存储模块820以及播放模块830。接收存储模块820被配置为存储从所述远程设备100接收到的与所述文本对应的语音，播放模块830被配置为在未来的播放点开始播放所述语音。如前文中所提到的，播放点基于与所述文本相关联的元数据而确定。

在一些实施例中，发送模块810还包括第一确定模块，被配置为响应于接收到激活语音播报事件的请求，根据语音播报事件确定将要通过语音播放的多条文本以及相关联的元数据。发送模块810还被配置为将所述多条文本中的至少部分文本发送至所述远程设备100。

在一些实施例中，发送模块810还包括第二确定模块，被配置为基于可用于存储语音数据的本地存储容量，来确定向所述远程设备100发送的文本的量。

在一些实施例中，发送模块810还包括第三确定模块，被配置为确定所述文本被转换为所述语音所需的预计处理时长。在一些实施例中，发送模块810还包括传输模块，被配置为响应于到达所述播放点所需的预计等待时长超过所述预计处理时长并且二者之差在预定范围内，将所述文本传输至所述远程设备100。

在一些实施例中，第三确定模块还被配置为基于单个的文本语音转换所需的平均时长和所述文本中包含的字数，来确定针对所述文本的所述预计处理时长。

在一些实施例中，第三确定模块还包括通信状况确定模块、数据量确定模块以及时长确定模块。通信状况被配置为确定模块确定与所述远程设备100之间的通信状况。数据量确定模块被配置为确定所述文本和所述语音的数据量。时长确定模块被配置为根据所述数据量和所述通信状况来确定所述预计处理时长。

在一些实施例中，装置800还包括等待时长确定模块。等待时长确定模块包括移动速度获取模块，被配置为获取装置800的当前移动速度。等待时长确定模块还包括第四确定模块，被配置为基于所述当前移动速度以及与所述播放点对应的位置，来确定所述预计等待时长。

图5示出了示出了其中可以实施本公开的一个或多个实施例的计算设备900的框图。应当理解，图5所示出的计算设备900仅仅是示例性的，而不应当构成对本文所描述的实施例的功能和范围的任何限制。图5所示出的计算设备900可以用于实现前文中所提到的电子设备。

如图5所示，计算设备900是通用计算设备的形式。计算设备900的组件可以包括但不限于一个或多个处理器或处理单元910、存储器920、存储设备930、一个或多个通信单元940、一个或多个输入设备950以及一个或多个输出设备960。处理单元910可以是实际或虚拟处理器并且能够根据存储器920中存储的程序来执行各种处理。在多处理器系统中，多个处理单元并行执行计算机可执行指令，以提高计算设备900的并行处理能力。

计算设备900通常包括多个计算机存储介质。这样的介质可以是计算设备900可访问的任何可以获取的介质，包括但不限于易失性和非易失性介质、可拆卸和不可拆卸介质。存储器920可以是易失性存储器(例如寄存器、高速缓存、随机访问存储器(RAM))、非易失性存储器(例如，只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、闪存)或它们的某种组合。存储设备930可以是可拆卸或不可拆卸的介质，并且可以包括机器可读介质，诸如闪存驱动、磁盘或者任何其他介质，其可以能够用于存储信息和/或数据(例如用于训练的训练数据)并且可以在计算设备900内被访问。

计算设备900可以进一步包括另外的可拆卸/不可拆卸、易失性/非易失性存储介质。尽管未在图5中示出，可以提供用于从可拆卸、非易失性磁盘(例如“软盘”)进行读取或写入的磁盘驱动和用于从可拆卸、非易失性光盘进行读取或写入的光盘驱动。在这些情况中，每个驱动可以由一个或多个数据介质接口被连接至总线(未示出)。存储器920可以包括计算机程序产品925，其具有一个或多个程序模块，这些程序模块被配置为执行本公开的各种实施例的各种方法或动作。

通信单元940实现通过通信介质与其他计算设备进行通信。附加地，计算设备900的组件的功能可以以单个计算集群或多个计算机器来实现，这些计算机器能够通过通信连接进行通信。因此，计算设备900可以使用与一个或多个其他服务器、网络个人计算机(PC)或者另一个网络节点的逻辑连接来在联网环境中进行操作。

输入设备950可以是一个或多个输入设备，例如鼠标、键盘、追踪球等。输出设备960可以是一个或多个输出设备，例如显示器、扬声器、打印机等。计算设备900还可以根据需要通过通信单元940与一个或多个外部设备(未示出)进行通信，外部设备诸如存储设备、显示设备等，与一个或多个使得用户与计算设备900交互的设备进行通信，或者与使得计算设备900与一个或多个其他计算设备通信的任何设备(例如，网卡、调制解调器等)进行通信。这样的通信可以经由输入/输出(I/O)接口(未示出)来执行。

根据本公开的示例性实现方式，提供了一种计算机可读存储介质，其上存储有计算机可执行指令，其中计算机可执行指令被处理器执行以实现上文描述的方法。根据本公开的示例性实现方式，还提供了一种计算机程序产品，计算机程序产品被有形地存储在非瞬态计算机可读介质上并且包括计算机可执行指令，而计算机可执行指令被处理器执行以实现上文描述的方法。

这里参照根据本公开实现的方法、装置、设备和计算机程序产品的流程图和/或框图描述了本公开的各个方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机可读程序指令实现。

这些计算机可读程序指令可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理单元，从而生产出一种机器，使得这些指令在通过计算机或其他可编程数据处理装置的处理单元执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。

可以把计算机可读程序指令加载到计算机、其他可编程数据处理装置、或其他设备上，使得在计算机、其他可编程数据处理装置或其他设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其他可编程数据处理装置、或其他设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。

附图中的流程图和框图显示了根据本公开的多个实现的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分，模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上已经描述了本公开的各实现，上述说明是示例性的，并非穷尽性的，并且也不限于所公开的各实现。在不偏离所说明的各实现的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实现的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其他普通技术人员能理解本文公开的各个实现方式。

Claims (12)

1.一种文本语音转换的方法，包括：

将文本发送至远程设备以进行文本语音转换；

存储从所述远程设备接收到的与所述文本对应的语音；以及

在未来的播放点开始播放所述语音，所述播放点基于与所述文本相关联的元数据而确定。

2.根据权利要求1所述的方法，其中将所述文本发送至所述远程设备包括：

响应于接收到激活语音播报事件的请求，根据所述语音播报事件确定将要通过语音播放的多条文本以及相关联的所述元数据；以及

将所述多条文本中的至少部分文本发送至所述远程设备。

3.根据权利要求1所述的方法，其中所述播放点表示时间或者位置。

4.根据权利要求1所述的方法，其中将所述文本发送至所述远程设备包括：

基于可用于存储语音数据的本地存储容量，来确定向所述远程设备发送的文本的量。

5.根据权利要求1所述的方法，其中将所述文本发送至所述远程设备包括：

确定所述文本被转换为所述语音所需的预计处理时长；

响应于到达所述播放点所需的预计等待时长超过所述预计处理时长并且二者之差在预定范围内，将所述文本传输至所述远程设备。

6.根据权利要求5所述的方法，其中确定所述预计处理时长包括：

基于单个的文本语音转换所需的平均时长和所述文本中包含的字数，来确定针对所述文本的所述预计处理时长。

7.根据权利要求5所述的方法，其中确定所述预计处理时长包括：

确定与所述远程设备之间的通信状况；

确定所述文本和所述语音的数据量；

根据所述数据量和所述通信状况来确定所述预计处理时长。

8.根据权利要求5所述的方法，其中确定所述等待时长包括：

获取当前移动速度；

基于所述当前移动速度以及与所述播放点对应的位置，来确定所述预计等待时长。

9.一种文本语音转换的装置，包括：

发送模块，被配置为将文本发送至远程设备以进行文本语音转换；

接收存储模块，被配置为存储从所述远程设备接收到的与所述文本对应的语音；以及

播放模块，被配置为在未来的播放点开始播放所述语音，所述播放点基于与所述文本相关联的元数据而确定。

10.一种电子设备，所述设备包括：

一个或多个处理器；以及

存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-8中任一项所述的方法。

11.一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现如权利要求1-8中任一项所述的方法。

12.一种计算机程序产品，包括计算机可执行指令，其中所述计算机可执行指令在被处理器执行时实现如权利要求1-8中任一项所述的方法。