发明内容
本发明要解决的技术问题在于,针对现有技术的上述编码处理要使用宝贵的主处理器资源的缺陷,提供一种处理数据的方法和系统,该方法和系统能够为蓝牙流音频应用提供最优结构。
根据本发明的一方面,提供一种处理数据的方法,包括在蓝牙收发器芯片上使用所述蓝牙收发器芯片内的音频编解码器压缩音频信息。
优选地,所述音频编解码器包括低复杂度的次频带编解码器(SBC)。
优选地,该方法还包括在所述蓝牙收发器芯片外部产生包含所述音频信息的音频数据流。
优选地,所述音频数据流是通过所述蓝牙收发器芯片外部的音/视频分布式传输协议(AVDTP)生成。
优选地,该方法,还包括通过蓝牙收发器芯片在蓝牙主设备和对等的蓝牙设备之间建立数据信道,以将所生成的音频数据流传递给所述蓝牙收发器芯片进行压缩。
优选地,该方法还包括通过至少使用以下之一:逻辑链路控制和适配协议(L2CAP)和高级音频分布框架(A2DP)建立所述数据信道。
优选地,该方法还包括在所述蓝牙收发器芯片中确定包含所述压缩音频信息的至少一个音频帧的帧尺寸。
优选地,该方法还包括在所述蓝牙收发器芯片中基于所确定的帧尺寸将所述至少一个音频帧格式化。
优选地,所述格式化至少包括以下之一:分割所述至少一个音频帧、组合多个所述音频帧。
优选地,该方法还包括通过所述蓝牙收发器芯片内的音/视频分布式传输协议(AVDTP)将所述至少一个音频帧格式化。
优选地,所述方法还包括通过脉冲编码调制(PCM)有线连接从所述蓝牙收发器芯片外部获取所述音频信息。
根据本发明的一方面,提供一种处理数据的系统,该系统包括蓝牙收发器芯片,所述蓝牙收发器芯片包括用于压缩所接收到的音频信息的片载音频编解码器。
优选地,所述音频编解码器包括低复杂度的次频带编解码器(SBC)。
优选地,所述蓝牙收发器芯片通过蓝牙收发器芯片外部的协议栈接收包含所述音频信息的音频数据流。
优选地,所述接收到的音频数据流是通过所述蓝牙收发器芯片外部的所述协议栈内的音/视频分布式传输协议(AVDTP)产生。
优选地,通过所述蓝牙收发器芯片在蓝牙主设备和对等的蓝牙设备之间建立数据信道,以将所生成的音频数据流传递给所述蓝牙收发器芯片进行压缩。
优选地,所述数据信道是通过使用所述蓝牙收发器芯片外部的协议栈内的至少以下协议之一:逻辑链路控制和适配协议(L2CAP)和高级音频分布框架(A2DP)而建立。
优选地,所述蓝牙收发器芯片在芯片中确定包含所述压缩音频信息的至少一个音频帧的帧尺寸。
优选地,所述蓝牙收发器芯片在芯片中基于所确定的帧尺寸将包含所述压缩音频信息的至少一个音频帧格式化。
优选地,所述蓝牙收发器芯片通过至少以下方式之一在芯片上格式化至少一个音频帧:分割至少一个音频帧、组合多个音频帧。
优选地,所述蓝牙收发器芯片使用音/视频分布式传输协议(AVDTP)将所述至少一种音频帧格式化。
优选地,所述蓝牙收发器芯片通过脉冲编码调制(PCM)有线连接获取所述音频信息。
根据本发明的一方面,提供一种计算机可读的存储器,其上存储有计算机程序,所述计算机程序包括至少一个用于处理数据的代码段,当计算机执行该至少一个代码段时,能使计算机执行以下步骤:使用所述蓝牙收发器芯片内的音频编解码器压缩音频信息。
优选地,所述音频编解码器包括低复杂度的次频带编解码器(SBC)。
优选地,所述计算机可读的存储器还包括用于在所述蓝牙收发器芯片外部生成包含所述音频信息的音频数据流的代码。
优选地,所述音频数据流是通过所述蓝牙收发器芯片外部的音/视频分布式传输协议(AVDTP)生成。
优选地,所述计算机可读的存储器还包括用于通过蓝牙收发器芯片在蓝牙主设备和对等的蓝牙设备之间建立数据信道的代码,以将所生成的音频数据流传递给所述蓝牙收发器芯片进行压缩。
优选地,所述计算机可读的存储器还包括用于至少使用以下之一:逻辑链路控制和适配协议(L2CAP)和高级音频分布框架(A2DP)建立所述数据信道的代码。
优选地,所述计算机可读的存储器还包括用于在所述蓝牙收发器芯片中确定包含所述压缩音频信息的至少一个音频帧的帧尺寸的代码。
优选地,所述计算机可读的存储器还包括:
用于基于所确定的帧尺寸在所述蓝牙收发器芯片内将所述至少一个音频帧格式化的代码,所述格式化至少包括以下之一:分割所述至少一个音频帧、组合多个所述音频帧;以及
用于通过所述蓝牙收发器芯片内的音/视频分布式传输协议(AVDTP)将所述至少一个音频帧格式化的代码。
从以下的描述和附图中,可以得到对本发明的各种优点、各个方面、创新特征、及其实施例细节的更深入的理解。
具体实施方式
本发明涉及为蓝牙流音频应用提供最优结构的方法和系统。本发明的一方面通过蓝牙将流音频提供给蓝牙设备。在这点上,最优结构使用蓝牙芯片——该芯片可集成在蓝牙设备中——来直接处理音频数据的SBC编码操作。由于SBC编码操作是在蓝牙设备中直接完成,内部编码所得到的音频数据可通过蓝牙协议直接传递给外部的蓝牙设备(例如蓝牙耳机)或者传递给手机的内部设备。
在本发明的另一个实施例中,在这种配置之下,蓝牙芯片提供SBC编码处理过程的的硬件加速。所述蓝牙芯片可用于从脉冲编码调制(PCM)有线CODEC接口(例如标准硬件立体声PCM接口)接收输入的音频信号。所述蓝牙芯片可在硬件方面加速输入音频信号的SBC编码处理,从而释放了主处理器通常用于进行SBC音频编码的那部分处理资源。
图1是蓝牙(BT)流音频设备一些实例的示意图。参考图1,图中示出了立体耳机104、移动电话106、蓝牙立体声音响系统108、个人计算机(PC)110和102、立体扬声器102a和102b。立体耳机104可接收存储在移动电话106上的MP3文件的流音频。耳机104还可以作为用于电话呼叫的标准蓝牙电话耳机。蓝牙立体声音响系统108可接收存储在PC 110中的MP3文件的流音频,解决了如何在立体声音响系统108上获取PC 110中的MP3的流音频的问题。PC 102可通过扬声器102a和102b播放立体声音频,使桌面避免了各种连线的杂乱。
蓝牙协议使用在2.4GHz的免许可频段(Unlicensed Band)上运行的跳频扩频(FHSS)无线系统。低发射功率使其有效范围约为10米。设备之间互相连接,形成所谓的微微网,微微网中活动的设备数可达7部。设备之间的最大数据吞吐量是2.0至3.0兆比特每秒(Mbps),这一数据容量由微微网中的设备所共享。
蓝牙协议使用协议栈传输数据和实现各种应用程序要求的各种高级特性。蓝牙协议栈包括为不同目的而设计的多种不同的协议。各种框架或应用程序存放在协议栈上,并使用蓝牙协议栈提供的服务。蓝牙协议也包括下层协议栈,用于链路管理和基带控制。
蓝牙协议栈中的一种或多种协议可存放于主设备中,例如具有蓝牙功能的设备。蓝牙协议栈中的其他协议,例如下层蓝牙协议栈中的协议,可存放于蓝牙芯片上。在这点上,SBC编码处理,或者音频数据的压缩将从上层蓝牙协议栈转移到位于蓝牙芯片中的下层蓝牙协议栈。从而释放了由蓝牙设备的主处理器处理的处理资源,所释放的处理资源可作他用。
图2是简化的协议栈的示意图。参考图2,所示的是典型的蓝牙协议栈201。典型的蓝牙协议栈201可包括框架层(Profile Layer)202、蓝牙管理实体(BTM)层204、射频通信(RFCOMM)协议206、音/视频分布式传输协议(AVDTP)207、服务发现协议(SDP)208、逻辑信道控制和适配协议(L2CAP)210、主控制器接口(HCI)212以及下层栈214。框架层202可包括一种或多种应用程序的框架,这些应用程序可用于与蓝牙协议栈连接。BTM层204通过整合蓝牙模块,使各种设备具有无线通信功能。RFCOMM协议206可用于在L2CAP协议上提供RS-232串行端口的仿真,为上层服务提供传输能力,例如使用串行线作为传输机制的OBEX。
SDP 208可用于查询蓝牙设备信息、蓝牙设备服务以及服务的特性。L2CAP210可用于支持上层协议复用、数据包分段与重组、服务质量(QoS)。L2CAP 210允许上层协议以及应用程序发送和接收长度达64k字节的数据包。HCI 212可用于给基带控制器、链路管理器提供命令接口,并可访问硬件状态和控制寄存器。
音/视频分布式传输协议(AVDTP)207是为蓝牙流音频和视频而特别设计的协议。该协议可执行用于配置、打开和/或关闭蓝牙设备之间的数据流的信令。可使用实时协议(RTP)数据包传输音频流数据。协议栈中AVDTP位于L2CAP之上,对于信令和数据可使用分立的L2CAP信道。
下层栈214可包括链路管理协议(LMP)215和链路控制器(LC)217。链路管理器(LM)215可用于实现链路建立、验证、链路配置和其他协议。链路管理器215可发现其他的远程LM,并通过LMP与他们通信。为完成自己的服务提供方任务,LM 215使用下面的链路控制(LC)217。LMP本质上包括很多协议数据单元(PDU),这些PDU可从一个设备发送到另一个设备,例如由数据包报头的地址确定的另一个设备。LMP 215可控制各种蓝牙设备之间的通信,例如电话机和PC之间的通信。
在下层协议栈214中的LC 217可用于管理蓝牙基带功能,如音频和/或数据包的编码、纠错、时隙定界、跳频、无线电接口、数据加密和/或链路验证。此外,LC 217可用于执行与LMP 215有关的链路管理软件。例如,链路管理的控制可包括建立通信链路和执行验证、配置以及其他的协议。在本发明的实施例中,下层栈214可包括使用SBC编码或压缩的高级音频分布框架(A2DP)。在这点上,在下层栈214中实施的A2DP可用于处理音频数据格式化操作,例如压缩或编码。
蓝牙硬件通常是包括一个或两个芯片的高度集成的系统。图3是典型的蓝牙硬件实施的示意框图。参考图3,蓝牙硬件包括蓝牙基带集成电路(IC)305和无线电IC 301。无线IC 301可包括蓝牙无线收发装置303。基带IC 305可包括蓝牙基带电路307、处理器309、随机访问存储器(RAM)311、只读存储器(ROM)313、语音CODEC 321、串行外围接口(SPI)319、通用串行总线(USB)317以及通用异步接收器/发射器(UART)315。无线IC 301可用单独的芯片实现。处理器309可用于运行全部所需的软件,例如,包括下层栈、上层的栈以及嵌入框架。这种类型的单CPU实现允许小的、低功率的以及低成本的解决方案。
吞吐量为723kbps的蓝牙链路适用于MP3和/或其他编码格式的流音频。蓝牙流音频可由覆盖协议和框架的三个蓝牙规范定义,包括AVDTP、GAVDP以及A2DP。音/视频分布式传输协议(AVDTP)是为蓝牙流音频和视频而特别设计的协议。该协议可实现用于配置、打开和/或关闭蓝牙设备之间的数据流的信令。可使用实时协议(RTP)数据包传输音频流数据。AVDTP位于协议栈中L2CAP之上,信令和数据可使用分立的L2CAP信道。
通用音/视频分布式框架(GAVDP)是定义应用程序如何使用AVDTP的概要性框架。高级音频分布式框架(A2DP)定义如何运行蓝牙流音频应用程序。例如,A2DP定义如何为MPEG和/或其他编解码器获得和设定音频CODEC参数。A2DP也可以定义媒体有效载荷格式以将音频流数据打包,可以包括低复杂度的次频带CODEC(SBC)的规范。在这点上,SBC可在蓝牙基带IC 305内的芯片上实现,可用于将从无线IC 301接收的未压缩数据进行音频数据压缩。例如,SBC可在处理器309中实现,或者可以作为单独的压缩加速模块在处理器309外实现。
图4是用于流音频的蓝牙协议栈的示意框图。参考图4,用于流音频的蓝牙协议栈401可包括A2DP 402、蓝牙管理实体(BTM)协议404、GAVDP/AVDTP406、服务发现协议(SDP)408、逻辑链路控制和适配协议(L2CAP)410、主控制器接口(HCI)412和下层栈414。除了图4所示的蓝牙规范之外,还有多种用于蓝牙流音频的ISO/IEC和网际RFC规范,现概括于表1中:
规范 |
描述 |
ISO/IEC 11172 part 3 |
MPEG音频 |
ISO/IEC 13818 part 3 |
MPEG音频 |
ISO/IEC 13818 part 7 |
MPEG高级音频 |
ISO/IEC 14496 part 3 |
MPEG高级音频 |
RFC 1889 |
实时协议(RTP) |
RFC 2733 |
RTP纠错 |
RFC 3095 |
数据报文报头压缩 |
RFC 2250 |
RTP有效载荷格式 |
RFC 3016 |
RTP有效载荷格式 |
RFC 3119 |
RTP有效载荷格式 |
表1.用于蓝牙流音频的其他规范
A2DP 402可包括低复杂度的次频带CODEC(SBC)403。例如,SBC 403可用于对音频数据进行压缩,或者对从蓝牙无线收发器接收的未压缩数据进行编码。
大多数蓝牙数据流A/V系统都在AVDTP协议中实现。图5A是AVDTP特征的示意图。参考图5A,AVDTP可包括蓝牙协议栈501位于蓝牙协议框架503之下的一部分,如A2DP,可分成四个子系统:信令502、数据流管理504、恢复506、适配层508。AVDTP信令消息502用于发现、配置、打开以及关闭两个蓝牙设备之间的数据流。有11种消息类型,其中一些消息是可选的。
数据流管理器504的媒介传输特性可用于传输包含音频数据的RTP数据包,该特性是AVDTP必需的特性。数据流管理器504的报告特性使得能够通过使用RFC 1889定义的协议交换链路质量信息,如信号不稳定或者数据包丢失。该特性是可选的。恢复特性506在数据传输中添加了包括纠错数据的额外数据包,使得丢失的数据包能够得以恢复。这种恢复机制由RFC 2733定义,是一个可选的特性,需要额外的ROM和/或RAM。
如RFC 3095所定义的,适配层508的报头压缩特性使得RTP报头得以压缩。使用AVDTP时,可将RTP报头减少5至7字节。与实现该特性所付出的代价相比,这种节省可能是不值得的,特别是使用大的媒体数据分组时。AVDTP适配层508的复用特性使得媒介、报告和/或恢复数据分组能够共享L2CAP信道,从而实现了更少的L2CAP信道以及更好地利用基带信道容量。对于使用具有报告和恢复的多个并发数据流的设备而言,这一复合(complex)特性是有用的。
在本发明的一个实施例中,AVDTP能使用数据格式化功能。例如,AVDTP可在数据流管理器504中使用音频数据格式化功能。例如,该格式化功能可用于通过SBC在芯片上对音频数据进行压缩。即,数据流管理器504能建立数据格式参数,例如用于压缩音频数据的压缩参数;在蓝牙基带IC中实现的SBC可用于音频数据压缩。接着,压缩后的音频数据被传递给对等的蓝牙设备。
图5B是根据本发明一个实施例的用于流音频播放的典型硬件的示意框图。参考图5B,为流音频播放而实施的蓝牙硬件可包括蓝牙基带集成电路(IC)525,无线IC 521以及音频IC 543。无线IC 521包括蓝牙无线收发装置523。音频IC 543包括MP3解码器545以及立体声编解码电路547。基带IC 525包括蓝牙基带电路527、处理器529、随机存储存储器(RAM)531、只读存储器(ROM)533、音频编解码器541、串行外围接口(SPI)539、通用串行总线(USB)537以及通用异步接收器/发射器(RART)535。无线IC 521以及音频IC 543可在分立的芯片上实现。处理器529可用于运行全部所需的软件,例如,包括下层栈、上层栈以及嵌入框架。通过蓝牙链路接收的数据可由协议栈处理并传递给应用程序。应用程序可获得音频流数据,并通过硬件接口将音频流数据传递给音频IC 543。音频IC 543对数字音频进行解码,并将音频信号转换成模拟信号。
实施具有最少必需特性的AVDTP要求多数据流支持。对于图1所示的简单的流音频设备实施例,可不要求可选的特性如恢复、报告、报头压缩以及复用,因为这些简单的蓝牙设备没有这些特性也能适当地运行。
在蓝牙链路中,维持数据传输的恒定比特率是有困难的。如果数据发送太慢,音频解码器将有部分时间没有流数据处理,这会导致听觉可感受到的错误。丢失数据包也会导致相同的问题。另一方面,如果数据发送太快,那么数据将缓冲在音频解码器处,当设备用完缓冲空间时,最后会导致拥塞或者数据丢失。由于AVDTP或L2CAP没有内置的流量控制机制,所以可用其它的机制来防止数据丢失。音频源或发送数据流的设备使用的机制取决于源的类型。如果源是“实况转播”的并且音频流式数据由音频编码器提供,那么编码器本身就可提供恒定比特率。如果源来自文件,那么可使用定时器来维持恒定的比特率。
可通过下面这个实施例了解使用定时器的思想。设备正在从以码率为128kbps、采样频率为48kHz编码的文件上发送MP3数据流。参考表2a,这表明每24.0毫秒发送384字节长的MP3音频帧。如果设备简单地设置24.0毫秒的周期定时器,当定时器期满就发送一个数据包,就能够维持恒定的比特率。
音频帧尺寸vs.数据速率和采样频率 |
|
SBC* |
MP3 |
64kbps |
128kbps |
320kbps |
64kbps |
128kbps |
320kbps |
48kHz |
20 |
42 |
108 |
192 |
384 |
960 |
44.1kHz |
22 |
46 |
118 |
209 |
418 |
1045 |
32kHz |
32 |
64 |
162 |
228 |
576 |
1440 |
表2a:SBC和MP3的音频帧尺寸
音频帧周期vs.采样频率 |
|
SBC* |
MP3 |
48kHz |
2.667ms |
24.0ms |
44.1kHz |
2.902ms |
26.122ms |
32kHz |
4.0ms |
36.0ms |
表2b:SBC和MP3的音频帧周期
从表2b的SBC和MP3音频帧周期的几种典型值可以看到,SBC帧小,周期短。一些设备在如此短的时间间隔内使用定时器或者处理数据会出现问题。因此建议与其在每个短的时间间隔内发送包含单帧的小数据包,不如在更长的时间间隔上发送包含几个帧的较大的数据包。MP3帧的最大尺寸与AVDTP传输信道的L2CAP MTU对应,这样,无需将音频帧分割到多个AVDTP数据包上。
当在设备之间传输多于一个数据流时,数据流的播放可以同步。考虑图1所示的无线PC扬声器。该PC将蓝牙音频流传递给每个扬声器。实际上这个例子中有两个同步问题。首先,这两个扬声器的音频播放需要互相同步。其次,音频播放需要与PC的显示同步。虽然蓝牙规范中没有覆盖同步问题,但是可利用该系统的一些特性来解决这些同步问题。
图6是根据本发明一个实施例的在蓝牙主设备中的音频信号处理过程的示意图。参考图6,蓝牙设备或主机606包括中央处理单元(CPU)608和蓝牙收发器602。例如,CPU或处理器608使用低复杂度的次频带CODEC(SBC)模块610。蓝牙收发器602包括CPU 604。CPU 608可用于处理未压缩的音频数据。例如,CPU 608可使用SBC模块610编码或压缩未压缩的音频数据。蓝牙收发器602中的CPU 604可用于控制必需的蓝牙软件的处理,例如,包括下层蓝牙协议栈、上层的蓝牙协议栈和/或嵌入框架。
具体实施时,蓝牙设备606接收未压缩的音频数据612。蓝牙设备606还可用于从标准脉冲编码调制(PCM)有线CODEC接口(如标准硬件立体声PCM接口)接收未压缩的输入音频信号614。CPU 608使用SBC模块610将所述未压缩的音频数据压缩。将所得到的压缩音频数据616从SBC模块610传递给蓝牙收发器602。通过蓝牙协议将内部编码所得到的音频数据直接传递给外部的蓝牙设备。例如,蓝牙无线收发装置(如蓝牙收发器602内的蓝牙无线收发装置523)将所接收到的压缩信号(如RF压缩音频信号618)传输给对等的蓝牙设备。
在本发明的一个实施例中,可通过将SBC压缩功能转移到蓝牙收发器602上来,可以释放主CPU 608的处理资源。即,可将SBC功能从上层蓝牙协议栈转移到下层蓝牙协议栈,例如从上层的蓝牙A2DP到下层的蓝牙A2DP。
图7是根据本发明一个实施例的蓝牙协议栈的示意图。参考图6和图7,该示例性的蓝牙协议栈包括上层蓝牙协议栈以及下层蓝牙协议栈。所述上层蓝牙协议栈可在主机606上实现,包括上层A2DP 702、上层AVDTP 704、上层L2CAP 706和上层HCI 708。下层蓝牙协议栈在蓝牙收发器602中实现,包括下层HCI 710、LMP 712、下层A2DP、下层AVDTP 718、下层L2CAL 719和LC 720。所述下层A2DP可包括SBC 716。上层L2CAP 706、上层HCI 708、下层HCI 710、LMP 712以及LC 720能执行如上面图2、4以及5A中所述的相同的功能。上层蓝牙协议栈可用于处理来自主机的蓝牙协议的控制信令部分;而下层蓝牙协议栈可用于处理来自主控制器的蓝牙协议的数据处理/格式化部分。
在根据本发明的一个实施例中,SBC模块可从主机606中的上层蓝牙协议栈转移到蓝牙收发器602中的下层蓝牙协议栈中。即,带有SBC 716的下层A2DP 714可包括在位于下层HCI 710下面的协议层中。下层A2DP 714可用于建立信令信道,例如建立从主设备606到对等蓝牙设备之间的信令信道,以传输压缩音频数据。下层AVDTP 718可以在位于下层A2DP 714下面的蓝牙协议层实现,用于在压缩音频数据的处理过程中提供分割与组合功能。
例如,还可以基于压缩音频数据包的大小,将压缩音频数据进一步分割或组合。下层AVDTP 718可用于将多个SBC数据包压缩成单个的AVDTP数据包,以及在该AVDTP数据包上添加媒介有效载荷报头。下层L2CAP 719可用于支持较高层水平的协议复用、数据包分割和重组,以及与由下层A2DP 714和下层AVDTP 718协议处理的压缩音频帧有关的服务质量(QoS)处理。下层L2CAP 719可用于校验从下层AVDTP 718接收的AVDTP数据包(具有报头),并添加L2CAP报头。接着,将L2CAP数据包与报头传送给LC 720以进行进一步的基带处理和传输。
参考图7和图8,主设备806可以是蓝牙主设备,它能知道蓝牙收发器802可用于执行音频帧的编码或压缩。蓝牙主设备可使用标准的蓝牙协议和程序初始建立与对等蓝牙设备的连接。蓝牙主设备806与对等蓝牙设备之间的连接建立之后,蓝牙主设备806告知蓝牙收发器802可以通过特定的L2CAP信道(带有特定的L2CAP信道ID(CID))将未压缩的音频数据传递给蓝牙收发器802。这种告知可通过厂商特性命令(vendor specific command)例如上层HCI 708和/或下层HCI 710的厂商特性命令来完成。
接着,蓝牙主设备806将控制信息传递给蓝牙收发器802,所述控制信息用于SBC压缩,也用于为下层AVDTP 718和下层L2CAP 719构造AVDTP和L2CAP数据包。所述控制信息包括例如,SBC参数和/或建立蓝牙连接时议定的A2DP/AVDTP报头。当蓝牙收发器802从下层HCI 710接收到下一个HCI数据包时,蓝牙收发器802检查该HCI数据包是否属于特定的L2CAP CID。如果该HCI数据包不属于特定的L2CAP CID,就将该HCI数据包直接从下层HCI 710传递给LC 720。如果该HCI数据包属于特定的L2CAP CID,那么蓝牙收发器802组合来自上层L2CAP 706的L2CAP数据包的片段并将之传递给下层A2DP714和SBC 716以进行压缩。压缩后的数据包传递给下层AVDTP 718以进行发送。下层AVDTP 718将必需的报头添加到所接受的数据包上,并将所得到的报头和数据包传给下层L2CAP 719。下层L2CAP 719添加L2CAP报头,所得到的数据包和报头被传递给LC 720。
虽然使用SBC编码进行音频压缩,但本发明不限于此,本发明还可以使用其他的编码方法如MP3或AAC等。
图8是根据本发明一个实施例的在蓝牙收发器中的音频信号压缩的示意图。参考图8,蓝牙设备或主机806可包括中央处理单元(CPU)808和蓝牙收发器802。蓝牙收发器802可包括CPU 804,CPU804可使用低复杂度的次频带CODEC(SBC)模块810。CPU 804可用于处理从CPU 808接收到的未经压缩的音频数据。例如,CPU 804可用于使用SBC模块810编码或压缩未经压缩的音频数据。此外,蓝牙收发器802中的CPU 804可用于运行所有必需的蓝牙软件,包括下层蓝牙协议栈、上层蓝牙协议栈,和/或嵌入框架。
具体实施时,使用蓝牙设备806接收未经压缩的音频数据812。接着,通过连接814将该未经压缩的音频数据传给蓝牙收发器802。接着,蓝牙收发器802中的CPU 804使用SBC模块810压缩未经压缩的数据。蓝牙收发器802也用于通过标准脉冲编码调制(PCM)有线CODEC接口(如标准硬件立体PCM接口)接收未经压缩的输入音频信号816。可通过蓝牙协议将所得到的内部编码音频数据从蓝牙收发器802直接传递给外部的蓝牙设备。例如,位于蓝牙收发器802中的蓝牙无线收发装置(如图5B中的蓝牙无线收发装置523)可将压缩音频信号(如RF压缩音频信号)传递给对等的蓝牙设备。
虽然使用PCM接口来接收未经压缩的输入音频信号,但本发明不受此限制。本发明还可以使用其他类型的接口,例如I2S或其它的硬件接口来接收未经压缩的输入音频信号。
图9是根据本发明一个实施例的使用音频信号压缩的蓝牙收发器的示意图。参考图9,蓝牙收发器902包括发射/接收开关904、发射(Tx)模块906、接收(Rx)模块908、基带处理模块910以及压缩加速模块914。基带处理模块910包括CPU 912。基带处理模块910和CPU 912的功能与图3中所示的基带IC 305和处理器309的功能相同。
压缩加速模块914包括适当的电路、逻辑和/或编码,可用于压缩从基带处理模块910接收的音频数据。在本发明的一个实施例中,压缩加速模块914包括数字信号处理器,其实现低复杂度的次频带CODEC。
在本发明的另一个实施例中,蓝牙收发器芯片902可包括在CPU 912内的片载音频编解码器,该编解码器在芯片上压缩接收到的音频数据。例如,CPU 912内的音频编解码器包括低复杂度的次频带编解码器(SBC)。蓝牙收发器芯片902通过蓝牙收发器芯片902外部的协议栈接收包含音频信息的音频数据流。所接收的音频数据流可通过所述蓝牙收发器芯片902外部的协议栈内的音/视频分布式传输协议(AVDTP)产生。建立蓝牙收发器902与对等的蓝牙设备之间的数据信道,以将所生成的音频数据流传递给蓝牙收发器芯片902进行压缩。所述数据信道可通过使用蓝牙收发器芯片902外部的协议栈内的逻辑链路控制和适配协议(L2CAP)和/或高级音频分布框架(A2DP)建立。
蓝牙收发器芯片902可在芯片上确定包括压缩音频信息的至少一个音频帧的帧尺寸。示例性SBC音频帧的尺寸已列在上面的表2a中。蓝牙收发器芯片902在芯片上基于所确定的帧尺寸将包括压缩音频信息的音频帧格式化。蓝牙收发器芯片902在芯片上格式化音频帧包括分割音频帧、组合多个音频帧。蓝牙收发器芯片902在芯片上通过音/视频分布式传输协议(AVDTP)将音频帧格式化。蓝牙收发器芯片可在芯片上通过脉冲编码调制(PCM)有线连接获得音频信息。
图10是根据本发明一个实施例的在蓝牙设备内处理数据的步骤流程图。参考图8和10,在步骤1002中,通过蓝牙收发器芯片802外部的音/视频分布式传输协议(AVDTP)在蓝牙收发器芯片802外生成包含音频信息的音频数据流812。步骤1004中,通过蓝牙收发器芯片802建立蓝牙设备与对等的蓝牙设备之间的数据信道,以将所生成的音频数据流812传递给蓝牙收发器芯片802进行压缩。步骤1006中,在蓝牙收发器芯片802上使用音频CODEC(如在蓝牙收发器芯片802内实现的SBC 810)将未经压缩的音频信息812压缩。
相应地,本发明可以通过硬件、软件,或者软、硬件结合来实现。本发明可以在至少一个计算机系统中以集中方式实现,或者由分布在几个互连的计算机系统中的不同部分以分散方式实现。任何可以实现所述方法的计算机系统或其它设备都是可适用的。常用软硬件的结合可以是安装有计算机程序的通用计算机系统,通过安装和执行所述程序控制计算机系统,使其按所述方法运行。在计算机系统中,利用处理器和存储单元来实现所述方法。
本发明还可以通过计算机程序产品进行实施,所述程序包含能够实现本发明方法的全部特征,当其安装到计算机系统中时,通过运行,可以实现本发明的方法。本文件中的计算机程序所指的是:可以采用任何程序语言、代码或符号编写的一组指令的任何表达式,该指令组使系统具有信息处理能力,以直接实现特定功能,或在进行下述一个或两个步骤之后实现特定功能:a)转换成其它语言、编码或符号;b)以不同的格式再现。
本发明是通过几个具体实施例进行说明的,本领域技术人员应当明白,在不脱离本发明范围的情况下,还可以对本发明进行各种变换及等同替代。另外,针对特定情形或具体情况,可以对本发明做各种修改,而不脱离本发明的范围。因此,本发明不局限于所公开的具体实施例,而应当包括落入本发明权利要求范围内的全部实施方式。