安徽城乡建设厅官方网站wordpress 4评测

安徽城乡建设厅官方网站,wordpress 4评测,密云网站开发公司,网络品牌推广在无线音频的世界里#xff0c;一场静默却深刻的革命正在进行。 它#xff0c;就是LE Audio。 这不仅仅是一次技术迭代#xff0c;而是从底层重新定义声音如何被创造、传输和体验的范式转移。其复杂性令人敬畏——它并非单一技术#xff0c;而是一套精密的生态系统#…在无线音频的世界里一场静默却深刻的革命正在进行。它就是LE Audio。这不仅仅是一次技术迭代而是从底层重新定义声音如何被创造、传输和体验的范式转移。其复杂性令人敬畏——它并非单一技术而是一套精密的生态系统全新的LC3编解码器以超凡效率重塑音质与功耗的平衡多重串流音频让真无线立体声达到前所未有的稳定与同步而音频广播功能则打破了“一对一”连接的百年窠臼让声音如电台般自由播撒。然而正是这种复杂性构成了我们必须深入学习它的不可辩驳的理由。未来的声音图景将由它绘制从下一代真无线耳机、无障碍助听设备到公共场所的沉浸式音频导览、多语言广播乃至元宇宙中清晰无缝的语音交互。不了解LE Audio将意味着在即将到来的音频浪潮中失去对话的基石。这不仅仅关乎技术本身更关乎我们如何连接彼此如何感知世界。让我们共同开启这段探索之旅揭开LE Audio的复杂面纱看清它为何必将成为未来数年里每一个科技从业者、音频爱好者乃至普通用户都无法忽视的关键命题。接下来的系列文章我们将逐步拆解这座精妙的技术大厦。同时我也录制了一系列的Le audio视频有兴趣的可以咨询我会带领你们入门Le audio翻过大山眼下皆是风景------------------------------------------------------------------------------------------------------------------------------------------视频链接https://item.taobao.com/item.htm?id1001969040805mi_id000032T4qZX9WZoRwX6YbxlNUaZOfOI6XoxDx0jxsfnwlEcspma21xtw.29178619.0.0---------------------------------------------------------------------------------------------------------------------------------一. 概念CAP 是由蓝牙技术联盟Bluetooth SIG为 LE Audio 定义的基础性通用音频配置文件。它为所有基于 LE Audio 的音频应用如通话、媒体播放提供了一个公共的、可重用的功能和程序集合。简单来说CAP 是 LE Audio 音频功能的“基石”或“公分母”。1. CAP 的核心目标避免重复为所有音频用例电话、媒体等定义一套通用的底层操作避免每个高层配置文件都重复定义如何发现、配置、建立和控制音频流。确保互操作性确保不同厂商、不同类型的 LE Audio 设备手机、耳机、音箱、助听器在基础音频功能上能够互通。支持多种应用场景Use Cases作为底层框架支撑上层的各种具体应用配置文件如HAP(Hearing Aid Profile)助听器TMAP(Telephony and Media Audio Profile)电话与媒体最常见PBP(Public Broadcast Profile)公共广播2. CAP 提供的主要功能CAP 本身并不直接面向最终用户它为上层应用提供以下关键服务功能模块描述发现与配置发现对端设备的音频能力Published Audio Capabilities - PACs并基于双方的共同能力协商和配置音频流参数如编解码器LC3的采样率、帧长等。音频流控制提供建立、启动、暂停、释放单播音频流的通用命令和程序。这是所有音频应用共享的核心控制逻辑。组管理提供管理协调组Coordinated Set的基础功能。一个协调组包含多个同步播放音频的设备如一对真无线耳机CAP 定义了如何创建、修改和删除这样的组。内容控制提供内容控制IDCCID的管理用于标识音频内容的类型如媒体、通话、提示音以便设备能根据内容类型采取不同的处理策略如不同的音量、编解码器置。3. CAP 在协议栈中的位置CAP位于高层应用配置文件如TMAP和底层的LE Audio服务之间。一个简单类比可以把CAP看作一个“音频设备驱动程序框架”TMAP/HAP/PBP等是具体的应用程序如“音乐播放器”、“电话App”。CAP是它们共同依赖的底层驱动库提供了“打开扬声器”、“调节音量格式”、“连接多个音箱”等通用操作接口。应用程序TMAP调用驱动库CAP的接口来实现具体功能而无需自己从头实现如何控制硬件。4. CAP角色CAP 定义了三种角色接收端、发起端和控制端。4.1. 接收端(Acceptor)接收端是一种外围设备它负责渲染从发起端接收的音频和/或向发起端传输音频。实现接收端角色的设备示例包括头戴式耳机、耳塞、助听器、麦克风和扬声器。具体而言一个接收端能够传输和接收单播音频流。能够暴露音频流端点(ASEs)。能够接收广播音频流。能够根据上下文类型值所描述的不同用例发出可用性和支持信号。能够接收关于单播或广播音频流预期用途的上下文该用途由上下文类型值描述。能够通过CCID值接收关于单播或广播音频流与内容控制服务关联的信息。能够扫描广播音频流。能够将广播音频流的扫描任务委托给一个控制端。能够请求并接收广播码。能够接收来自控制端的请求以开始或停止接收广播音频流。能够接收来自控制端的请求以静音或调节其正在渲染的音频的音量。能够接收来自控制端的请求以静音或调节其麦克风的信号电平。能够托管CCP和MCP客户端。4.2. 发起端(Initiator)发起端是接收端的对应端。发起端是一个中央设备它发起与一个或多个接收端之间的音频流传输音频流在发起端和接收端之间流动。实现发起端角色的设备示例包括手机、个人电脑、媒体播放器、电视和基础设施设备。具体而言一个发起端能够传输和接收单播音频流。能够传输广播音频流。能够启动、更新或结束与一个或多个接收端之间的单播音频流。能够启动、更新或结束广播音频流。能够为加密的广播音频流提供广播码。能够通过上下文类型值提供关于单播或广播音频流预期用途的上下文。能够托管CCP和MCP服务器这些服务器可以通过CCID值与音频流关联。能够协调一组接收端并发现属于某个协调组成员的接收端。4.3. 控制端(Commander)控制端发起围绕音频的控制功能例如音量控制、媒体播放器的开始/停止或电话通话的控制。具有发起端或接收端角色的设备也可以同时实现控制端角色但控制端角色也可以是独立的设备。实现独立控制端角色的设备示例包括用于调节一对助听器音量的遥控器。实现发起端角色并同时具备控制端角色的设备示例包括用于调节一对助听器音量的手机。具体而言一个控制端能够代表一个接收端扫描广播音频流及其关联的元数据。能够获取与广播音频流关联的编解码器配置、CCID值和上下文类型值。能够请求并接收广播码。能够将广播音频流关联的广播码提供给接收端。能够请求接收端开始或停止接收由发起端传输的广播音频流并提供由上下文类型值描述的其用例信息。能够控制接收端所渲染音频的静音状态和/或音量。能够控制接收端上麦克风的静音状态和/或信号电平。能够协调一组接收端并发现属于某个协调组成员的接收端。4.4. 角色跟协议的关系CAP 是一种配置文件它在以下领域内运行采集与渲染控制(Capture and Rendering Control)在接收端设备组上控制音频输入和音量。音频流转场(Audio Stream Transitions)在设备组上启动、更新和停止单播及广播音频流。内容控制(Content Control)对内容进行控制。具体而言对于采集与渲染控制CAP 使用了VCP、MICP和CSIP。对于音频流转场CAP 使用了BAP和CSIP。对于内容控制CAP 使用了MCP和CCP。二. 通用协议要求在这里我们来介绍下整个公用profile的要求• 为音频流分配上下文类型(Context Type)值• 通过CCID值将内容控制服务实例关联到音频流• 检查接收设备在单播应用场景中的可用性• 验证接收设备对音频位置功能的支持• 识别协调组内的接收设备并在组成员间协调音频流切换、采集与渲染控制流程• 处理复用同一音频流的不同应用场景间切换• 管理发起设备与单个或多个接收设备上多个音频流端点ASE之间的单播音频流• 处理同一广播同步组BIG内多台设备对广播音频流的接收• 处理单播音频流与广播音频流间的双向切换1. Context Type上下文类型值例如通话、铃声、提示音和媒体用于描述音频流的当前应用场景。上下文类型值是位字段中的比特位。如果同时设置了多个上下文类型值则关联的音频流可同时服务于多个应用场景并可以混合来自多个源的音频。音频流必须至少设置一个上下文类型值。一共有以下类型Value值Label标签Description描述0x0000Prohibited禁止Prohibited禁止0x0001Unspecified未指定Identifies audio where the use case context does not match any other defined value, or where the context is unknown or cannot be determined.标识不匹配任何其他定义值、或上下文未知或无法确定的用例场景的音频。0x0002Conversational通话Conversation between humans, for example, in telephony or video calls, including traditional cellular as well as VoIP and Push-to-Talk.人与人之间的对话例如在电话或视频通话中包括传统蜂窝网络以及VoIP和对讲。0x0004Media媒体Media, for example, music playback, radio, podcast or movie soundtrack, or tv audio.媒体音频例如音乐播放、广播、播客、电影原声或电视音频。0x0008Game游戏Audio associated with video gaming, for example gaming media; gaming effects; music and in-game voice chat between participants; or a mix of all the above.与电子游戏相关的音频例如游戏媒体、游戏音效、参与者之间的游戏内语音聊天或以上所有内容的混合。0x0010Instructional教学Instructional audio, for example, in navigation, announcements, or user guidance.教学音频例如用于导航、公告或用户引导的音频。0x0020Voice Assistants语音助手Man-machine communication, for example, with voice recognition or virtual assistants.人机通信例如与语音识别或虚拟助手的交互。0x0040Live现场Live audio, for example, from a microphone where audio is perceived both through a direct acoustic path and through an LE Audio Stream.现场音频例如来自麦克风的音频该音频既通过直接声学路径也通过LE音频流被感知。0x0080Sound Effects音效Sound effects including keyboard and touch feedback; menu and user interface sounds; and other system sounds.音效包括键盘和触摸反馈音、菜单和用户界面音效以及其他系统声音。0x0100Notifications通知Notification and reminder sounds; attention-seeking audio, for example, in beeps signaling the arrival of a message.通知和提醒音用于引起注意的音频例如表示消息到达的提示音。0x0200Ringtone铃声Alerts the user to an incoming call, for example, an incoming telephony or video call, including traditional cellular as well as VoIP and Push-to-Talk.提醒用户有来电的音频例如来电的电话或视频呼叫包括传统蜂窝网络以及VoIP和对讲。0x0400Alerts警报Alarms and timers; immediate alerts, for example, in a critical battery alarm, timer expiry or alarm clock, toaster, cooker, kettle, microwave, etc.闹钟和定时器即时警报例如在电池电量严重不足警报、计时器到期、闹钟、烤面包机、炊具、水壶、微波炉等中。0x0800Emergency Alarm紧急警报Emergency sounds, for example, fire alarms or other urgent alerts.紧急声响例如火警或其他紧急警报。发起设备将上下文类型值与音频流相关联以告知接收设备这些音频流的当前应用场景。接收设备可以根据上下文类型值实现相应的策略来对不同应用场景进行优先级排序并向发起设备表明其对于新的或更新的单播应用场景的可用性。例如接收设备可以优先处理来自一个发起设备的电话通话而非来自另一个发起设备的媒体流。发起设备通过使用BAP可用音频上下文发现过程来确定接收设备对于单播应用场景的可用性。对于在单个发起设备上、使用单条音频流服务于多个应用场景时如何混合来自不同实体的音频CAP未作定义。因此是否以及如何根据需要组合多个上下文类型值以同时将单条音频流关联到多个应用场景由具体实现自行决定。接收设备可以通过在已发布的音频能力PAC记录的元数据字段中使用Preferred_Audio_Contexts 元数据 LTV 结构将该 PAC 记录与特定的上下文类型值相关联以表达该 PAC 记录更倾向于用于具有指定上下文类型值的音频流。接收设备可以通过设置其支持的音频上下文特性和可用音频上下文特性中的单个比特位向发起设备提供关于其是否倾向于参与由某个上下文类型值描述的特定应用场景的信息。Supported Audio ContextsAvailable Audio ContextsInterpretation for Initiator (发起设备解读)Comment0b00b0如果在可用音频上下文中代表“未指定”的位设置为0b1则音频流上下文类型值可替换为“未指定”—0b00b1不适用不允许0b10b0发起设备不得使用此上下文类型值建立单播音频流—0b10b1发起设备可以使用此上下文类型值建立单播音频流—1.1. MCS/GMCS Context Type类型1.2. TBS/GTBS Context Type类型2. Content Control Identifier内容控制服务是一种控制音频相关功能或提供其状态信息的服务。例如电话承载服务TBS和媒体控制服务MCS。内容控制服务位于内容控制服务器上供内容控制客户端使用。内容控制标识符是一个唯一的标识符值即CCID值。CCID值用于标识一个内容控制服务并且在该设备上所有内容控制服务实例中该标识符对于该服务实例是唯一的。内容控制服务实例会实例化CCID特性。CCID特性在通用音频服务GSS中定义。当一个音频流承载由内容控制服务控制的内容时发起设备必须在该音频流的元数据中包含一个CCID值列表以告知接收设备单播或广播场景或指挥设备广播场景该音频流与一个或多个内容控制服务实例的关联关系。CCID值使得已与发起设备建立连接的接收设备或指挥设备能够通过查找内容控制服务过程参见第7.3.3节在发起设备上找到控制该音频流相关应用程序的内容控制服务实例。三. Acceptor role requirements四. Initiator role requirements五. Commander role requirements