日本久久中文字幕,欧美日韩中文字幕免费不卡

　　從今天的章節(jié)開始，我們將逐一介紹MRCP協(xié)議棧中媒體處理方式的內(nèi)容。語音合成是我們今天重點介紹的內(nèi)容。MRCP的語音合成處理是對普通文本或描述文本文件，然后實時通過媒體傳輸合成的語音。在前面的章節(jié)中，我們曾經(jīng)介紹過其兩種基本的類型，為了本章節(jié)的內(nèi)容，這里我們再次回憶一下這些內(nèi)容。MRCP中的語音合成包括兩種基本的媒體處理類型：一直是basicsynth，另外一種是speechsynth。前者的媒體處理類型僅能支持簡單的語音合成和非常有限的單詞構成；后者則可以支持全功能的語音合成和豐富的單詞語義，同時支持文本的渲染和其語音轉(zhuǎn)化合成功能。此此章節(jié)和接下來的章節(jié)中，我們將重點介紹這兩種媒體類型的method，事件和頭域的使用方式。

　　1、在討論媒體處理類型時，我們以前也討論了SSML的描述語法。這些語法可以支持不同的媒體處理類型和能力。首先，我們介紹一下兩個媒體資源類型所支持的SSML語法格式，請求方法，事件消息，狀態(tài)機和一些特別的頭域。

　　下面的列表中列出了兩種媒體資源類型所支持的相應的SSML要素以及輸入格式。

　　語音合成的媒體資源類型支持七個請求消息和兩個事件消息。七個請求的method分別是：

　　兩個事件消息分別是：

　　語音合成媒體資源支持一個狀態(tài)機。狀態(tài)機是由MRCP的客戶端來發(fā)起驅(qū)動，媒體資源自己本身則產(chǎn)生事件消息。

　　支持的各種特別的頭域列表：

　　2、現(xiàn)在，我們討論一下經(jīng)常使用的具體的method方法。SPEAK method 有兩個目的：提供語音合成的輸入，然后快速發(fā)起語音合成和媒體流數(shù)據(jù)。在SPEAK請求消息體中可包含：

inline 的SSML描述語法（application/ssml+xml）；
外部SSML的URL或文本列表；
inline的文本或多外部的消息；

　　3、合成媒體資源使用的是先進先出的隊列處理機制，因此處理過程是按照順序執(zhí)行，接收順序也是如此。當媒體資源接收到SPEAK請求時，如果媒體資源在空閑狀態(tài)，回復的響應請求狀態(tài)則是IN-PROGRESS 的消息；如果媒體資源是在講話狀態(tài)或暫停狀態(tài)時，響應的請求返回消息則是PENDING，表示此請求正在隊列中。這里讀者要注意，在合成請求中使用的一些語音參數(shù)是具有一定優(yōu)先級的。最高優(yōu)先級的是SSML描述語言，其次是SEPAK 請求中的相關語音參數(shù)：Voice-，Prosody-，Speaker-Profile 和 Speech-Language 頭；最低優(yōu)先級是會話默認值，它們使用SET-PARAMS和其接下來的后續(xù)method請求。以下是一個SPEAK請求示例圖：

　　其相應的客戶端到服務器端響應消息如下：

　　F1（client→speechsynth）:

MRCP/2.0338 SPEAK 3214
Channel-Identifier:23eb10a@speechsynth
Content-Type: application/ssml+xml
Content-Length: 213
<?xml version="1.0" encoding="UTF-8"?>
<speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis"
xml:lang="en-US">
Please leave a message after the beep.
<audio src="beep.wav"/>
</speak>

　　F2 （speechsynth → client）的回復消息如下：

MRCP/2.0 119 3214 200 IN-PROGRESS
Channel-Identifier: 23eb10a@speechsynth
Speech-Marker: timestamp=857206027059

　　F3 （speechsynth → client）:

MRCP/2.0 156 SPEAK-COMPLETE 3214 COMPLETE
Channel-Identifier: 23eb10a@speechsynth
Speech-Marker: timestamp=861500994355
Completion-Cause: 000 normal

　　4。如果MRCP客戶端對語音資源媒體講話表示一些內(nèi)容命令時，PAUSE請求method可以用來支持對合成媒體資源發(fā)出暫停語音輸出的請求。當語音輸出暫停以后，媒體資源會響應一個帶200 OK的狀態(tài)碼。如果在一個會話中，發(fā)出PAUSE 請求后，SPEAK不是一個活動的狀態(tài)，媒體資源服務器端必須對客戶端返回一個帶“Method not valid in this state” 的402 錯誤狀態(tài)碼。如果SPEAK請求是在活動狀態(tài)時，服務器端則必須返回一個Active-Request-Id-List，這個頭包含已被暫停的SPEAK 請求ID（注意，F(xiàn)4）。以下是一個暫停的示例圖：

　　相應的PAUSE 請求消息流程圖如下：

　　F1 （client → speechsynth）:

MRCP/2.0 187 SPEAK 3215
Channel-Identifier: 23eb10a@speechsynth
Content-Type: text/uri-list
Content-Length: 70
http://www.example.com/file01.ssml
http://www.example.com/file02.ssml

　　F2 （speechsynth → client）:

MRCP/2.0 118 3215 200 IN-PROGRESS
Channel-Identifier: 23eb10a@speechsynth
Speech-Marker: timestamp=857206027059

　　F3 （client → speechsynth）:

MRCP/2.0 67 PAUSE 3216
Channel-Identifier: 23eb10a@speechsynth

　　F4 （speechsynth → client）:

MRCP/2.0 105 3216 200 COMPLETE
Channel-Identifier: 23eb10a@speechsynth
Active-Request-Id-List: 3215

　　5、RESUME請求是對暫停的請求重啟。當語音生產(chǎn)重啟后，服務器端會對客戶端返回一個200 消息。Active-Request-Id-List 頭中會說明重啟的請求ID（注意 F6）。當服務器端處于空閑狀態(tài)時，服務器收到RESUME 請求時，它必須返回一個“402 Method not valid in this state” 消息。以下是一個重啟的示例圖：

　　這里，我們借用了前面的暫停消息流程，所以忽略了前面暫停的部分消息，僅展示重啟的消息流程（F5->F7）。

　　F5（client→speechsynth）:

MRCP/2.068 RESUME 3217
Channel-Identifier:23eb10a@speechsynth

　　F6（speechsynth→client）:

MRCP/2.01053217200 COMPLETE
Channel-Identifier:23eb10a@speechsynth
Active-Request-Id-List:3215

　　F7（speechsynth→client）:

MRCP/2.0155SPEAK-COMPLETE 3215 COMPLETE
Channel-Identifier:23eb10a@speechsynth
Speech-Marker:timestamp=861500994355
Completion-Cause:000 normal

　　6、STOP請求是對服務器端發(fā)出停止請求，通知服務器端停止處理語音輸出。如果在請求的消息中沒有攜帶Active-Request-Id-List，它說明在處理過程中的SPEAK請求已經(jīng)停止，任何在等待隊列中SPEAK請求已經(jīng)從隊列中移除。如果一個STOP請求成功停止了一個或多個PENDING 或IN-PROGRESS SPEAK 請求，則返回一個200 Success，并且在返回的200 消息中包含通過Active-Request-Id-List列出已經(jīng)成功停止的請求ID。以下是一個STOP 請求的示例圖：

　　F1（client→speechsynth）:

　　MRCP/2.0143 SPEAK 4000

　　Channel-Identifier:23eb10a@speechsynth

　　Content-Type:text/plain

　　Content-Length:28

　　Thankyou.Pleasecallagain.

　　F2（speechsynth→client）:

　　MRCP/2.0122 4000 200 IN-PROGRESS

　　Channel-Identifier:23eb10a@speechsynth

　　Speech-Marker:timestamp=857206027059

　　F3（client→speechsynth）:

　　MRCP/2.066 STOP 4001

　　Channel-Identifier:23eb10a@speechsynth

　　F4（speechsynth→client）:

　　MRCP/2.0145 4001 200 COMPLETE

　　Channel-Identifier:23eb10a@speechsynth

　　Speech-Marker:timestamp=861500994355

　　Active-Request-Id-List:4000

　　7、如果當一個活動的SPEAK請求中攜帶了頭Kill-On-Barge-In，并且這個值設置為true的時候，BARGE-IN-OCCURRED請求會明確執(zhí)行一個對STOP 請求的操作。BARGE-IN-OCCURRED的目的是MRCP 客戶端對媒體資源服務器端通信時，對服務器端發(fā)出的一個輸入事件，例如摁了DTMF按鍵或說話輸入觸發(fā)了收入的事件。語音合成資源服務器則根據(jù)輸入的數(shù)據(jù)來決定是否執(zhí)行結(jié)束輸入的流程。BARGE-IN-OCCURRED 打斷可以使用在以下兩種場景中：

語音識別引擎和語音合成資源是各自獨立的。
語音識別引擎和語音合成資源耦合度非常高，它們之間需要緊密配合。通常可能是同一廠家的產(chǎn)品。

　　在以上的使用場景中，MRCP客戶端的工作方式類似于一個proxy 代理的方式。它從服務器端接收到一個START-OF-INPUT事件，然后馬上對服務器端發(fā)送一個BARGE-IN-OCCURRED 打斷事件。如果是兩個服務器耦合度非常高的話，在接下來的由客戶端發(fā)出的BARGE-IN-OCCURRED請求中，MRCP客戶端會添加一個Proxy-Sync-Id 頭。如果服務器端已經(jīng)開始處理打斷事件的話，這個頭會支持服務器端來決定進一步的處理流程。在MRCP這樣的設計的目的就是MRCP客戶端無需獲悉MRCP服務器端是否直接在服務器使用了打斷的流程。

　　如果BARGE-IN-OCCURRED請求導致一個或多個SPEAK請求結(jié)束時，服務器端會返回一個 200 Success，并且包含一個Active-Request-Id-List頭來通知結(jié)束的請求ID。如果沒有結(jié)束SPEAK 請求的話，服務器端仍然返回200 Success，當然不會包含任何Active-Request-Id-List頭值。以下示例是一個打斷過示例圖：

　　這里，我們假設語音識別已經(jīng)通過RECOGNIZE 開啟了識別的請求狀態(tài)，這里沒有顯示。“internal barge-in message”使用在語音識別和合成服務器耦合工作的狀態(tài)中。現(xiàn)在讓我們看一下具體的消息發(fā)送流程：

　　F1 （client → speechsynth）:

　　MRCP/2.0 376 SPEAK 9200

　　Channel-Identifier: 23eb10a@speechsynth

　　Content-Type: application/ssml+xml

　　Content-Length: 251

　　<?xml version="1.0" encoding="UTF-8"?>

　　<speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis"

　　xml:lang="en-US">

　　Here is your track. You may pause at anytime by simply

　　saying pause.

　　</speak>

　　F2 （speechsynth → client）:

　　MRCP/2.0 118 9200 200 IN-PROGRESS

　　Channel-Identifier: 23eb10a@speechsynth

　　Speech-Marker: timestamp=857206027059

　　F3 （speechrecog → client）:

　　MRCP/2.0 134 START-OF-INPUT 10001 IN-PROGRESS

　　Channel-Identifier:a123c31f@speechrecog

　　Input-Type:speechProxy-Sync-Id:392812

　　F4（client→speechsynth）:

　　MRCP/2.0103 BARGE-IN-OCCURRED 9201

　　Channel-Identifier:23eb10a@speechsynth

　　Proxy-Sync-Id:392812

　　F5（speechsynth→client）:

　　MRCP/2.01449201 200 COMPLETE

　　Channel-Identifier:23eb10a@speechsynth

　　Speech-Marker:timestamp=861500994355

　　Active-Request-Id-List:9200

　　8、CONTROL請求是從客戶端發(fā)出的命令，通知語音合成資源服務器客戶端需要對客戶端說出的說話語音數(shù)據(jù)進行修改。簡單來說，就是客戶端通知語音合成服務器對剛才已說語音修改通知，可能客戶端對前面講話需要調(diào)整相關數(shù)據(jù)，例如可能調(diào)整說話人速度，說話人其他參數(shù)（Voice-或者Prosody-）等。這個調(diào)整可能完全取決于語音合成服務器端的功能支持，調(diào)整參數(shù)的設置通過CONTROL請求中添加頭值Jump-Size 來實現(xiàn)。注意，它僅能支持IN-PROGRESS SPEAK 請求。

　　如果CONTROL應用到了SPEAK請求中，服務器端回復一個200 Success消息，消息中包含Active-Request-Id-List 頭，而且?guī)б粋€活動的SPEAK 請求的ID。這個ID表示應用了CONTROL的ID。如果CONTROL發(fā)出以后，沒有任何SPEAK請求是在IN-PROGRESS 狀態(tài)的話，服務器端返回一個“402 Method not valid in this state”。

　　這里有一個比較特別的情況需要大家注意。當MRCP 客戶端在CONTROL請求中設定了Jump-Size 頭時，此跳轉(zhuǎn)超過了當前SPEAK請求起始值時，這個活動的請求會重新從起始值啟動，并且在響應中包含一個Speak-Restart 為true的頭。同樣，當MRCP 客戶端在CONTROL請求中設定了Jump-Size 頭時，此跳轉(zhuǎn)超過了當前SPEAK請求結(jié)束值時，這個活動的請求會馬上結(jié)束，攜帶了一個SPEAK-COMPLETE事件。以下是一個CONTROL的示例圖：

　　具體的CONTROL的消息流程如下：

　　F1（client→speechsynth）:

　　MRCP/2.0529 SPEAK 5000

　　Channel-Identifier:23eb10a@speechsynth

　　Content-Type:multipart/mixed;

　　boundary=0a23bf1020

　　Content-Length:388--0a23bf1020

　　Content-Type: text/uri-list

　　Content-Length: 32

　　http://www.example.com/menu.ssml

　　--0a23bf1020

　　Content-Type: application/ssml+xml

　　Content-Length: 198

　　<?xml version="1.0" encoding="UTF-8"?>

　　<speak version="1.0" xmlns="http://www.w3.org/2001/10/synthesis"

　　xml:lang="en-US">

　　Say operator to speak with a customer representative

　　</speak>

　　--0a23bf1020--

　　F2 （speechsynth → client）:

　　MRCP/2.0 118 5000 200 IN-PROGRESS

　　Channel-Identifier: 23eb10a@speechsynth

　　Speech-Marker: timestamp=857206027059

　　F3 （client → speechsynth）:

　　MRCP/2.0 114 CONTROL 5001

　　Channel-Identifier: 23eb10a@speechsynth

　　Jump-Size: +3 Second

　　Prosody-volume:+20%

　　F4（speechsynth→client）:

　　MRCP/2.01455001 200 COMPLETE

　　Channel-Identifier:23eb10a@speechsynth

　　Active-Request-Id-List:5000

　　Speech-Marker:timestamp=861500994355

　　F5（speechsynth→client）:

　　MRCP/2.0156 SPEAK-COMPLETE 5000 CO MPLETE

　　Channel-Identifier:23eb10a@speechsynthSpeech-Marker:timestamp=865795961651

　　Completion-Cause:000normal

　　9、DEFINE-LEXICON 請求是客戶端要求語音合成資源服務器加載或卸載此會話中的語法文件。DEFINE-LEXICON請求發(fā)出后，它要求當語音合成資源服務器在空閑狀態(tài)時，加載一些可能出現(xiàn)的大容量的語法文件。在請求中使用Load-Lexicon 頭來表示加載語法文件，這里默認設置問true，表示默認加載；如果是false，則表示下載語法文件。語法文件的數(shù)據(jù)格式可以支持在消息體中的inline的消息數(shù)據(jù)，也可以使用外部的URL（text/uri-list）支持外部的數(shù)據(jù)格式。如果DEFINE-LEXICON 請求失敗的話，例如，因為平臺的不同導致的語法格式不支持或者訪問出現(xiàn)問題的話，則會返回一個407 錯誤狀態(tài)碼（407 Method or operation failed）。

　　如果MRCP客戶端需要加載多個語法文件的話，可以通過SPEAK請求，在請求中通過Lexicon-Search-Order頭來設定。頭值中可以包含外部URL或session:URIs（引入inline 數(shù)據(jù)）。注意，加載語法文件時，SSML語法文件的優(yōu)先級會高于Lexicon-Search-Order 設定的優(yōu)先級。以下是一個DEFINE-LEXICON的示例圖：