專利名稱：通信終端的制作方法
技術領域：
本發(fā)明涉及通信終端，更具體的，涉及用于經諸如互聯(lián)網等通信網絡發(fā)送/接收音樂聲音控制數據的通信終端。
背景技術：
圖15是舉例說明在符合MIDI(樂器數字接口)標準的電子樂器、設備等(以下稱“MIDI設備”)之間的連接狀態(tài)的圖。各個MIDI設備經MIDI電纜連接，并且在一個MIDI設備中產生的MIDI消息(音樂聲音控制數據)經MIDI電纜被發(fā)送給另一個MIDI設備。
在這種方式中，經MIDI電纜發(fā)送/接收MIDI消息是常見的。近年來，通信網絡已經有了很大發(fā)展，對于通過經互聯(lián)網發(fā)送/接收MIDI消息來實現(xiàn)二重奏演奏或合奏曲(會話)的需求正在增長。
然而，在現(xiàn)有的傳輸系統(tǒng)中并沒有預先假定缺乏MIDI消息等情況。因此出現(xiàn)了這樣的問題即使將現(xiàn)有的傳輸系統(tǒng)照原樣應用到易于產生傳輸錯誤等的互聯(lián)網傳輸中，由于MIDI消息的缺乏等等的產生，也無法完全忠實地再現(xiàn)演奏。
鑒于這種情況，在IETF(互聯(lián)網工程任務組)中創(chuàng)設了用于MIDI標準的RTP有效載荷格式(例如，參見非專利文獻1)。這種用于MIDI的RTP有效載荷格式被用于經諸如互聯(lián)網等數據包傳輸網絡發(fā)送MIDI消息，并且具有這樣的特征，即使得能夠以高效率實現(xiàn)具有高可靠性的數據傳輸。
非專利文獻1
互聯(lián)網URLhttp://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-midi-format-07.txt。
然而，為了基于該用于MIDI標準的RTP有效載荷格式執(zhí)行傳輸，在MIDI設備中不僅需要安裝被用作與互聯(lián)網通信相關的協(xié)議組的核心的TCP(傳輸控制協(xié)議)和UDP(用戶數據報協(xié)議)，而且還需要安裝諸如RTP(實時傳輸協(xié)議)、RTCP(實時控制協(xié)議)、SDP(會話描述協(xié)議)等必須耗費大量資源(CPU資源、存儲器資源等)的協(xié)議。盡管如此，目前的狀態(tài)是諸如電子樂器等的平臺在CPU資源、存儲器資源等中沒有足夠的空間來安裝如RTP、RTCP、SDP等協(xié)議。

發(fā)明內容
由于前面所述的情況而作出了本發(fā)明，本發(fā)明的目的是提供一種通信終端，其能夠經互聯(lián)網有效地發(fā)送/接收MIDI消息等，而無需實施諸如RTP、RTCP、SDP等等豐富的協(xié)議。
為了實現(xiàn)上述目的，本發(fā)明的特征在于具有以下方案。
(1).一種通信終端，其中整合了面向連接類型的協(xié)議和無連接類型的協(xié)議，該通信終端包括輸入單元，其輸入音樂聲音控制數據；數據包生成器，將所述輸入的音樂聲音控制數據分別分類到第一和第二系統(tǒng)，并將分類屬于第一或第二系統(tǒng)的音樂聲音控制數據整理成數據包以產生音樂聲音控制數據包；以及發(fā)送器，通過使用面向連接類型的協(xié)議將屬于第一系統(tǒng)的音樂聲音控制數據包發(fā)送到目標終端，并通過使用無連接類型的協(xié)議將屬于第二系統(tǒng)的音樂聲音控制數據包發(fā)送到目標終端。
(2).根據(1)的通信終端，進一步包括第一分配單元，將表示傳輸順序的序號分配給通過使用面向連接類型的協(xié)議或無連接類型的協(xié)議發(fā)送的所有音樂聲音控制數據包。
(3).根據(2)的通信終端，其中，所述第一分配單元將用于標識音樂聲音控制數據包的序號和已分配給在前的已通過使用面向連接類型的協(xié)議發(fā)送的音樂聲音控制數據包的序號分配給通過使用無連接類型的協(xié)議發(fā)送的每個音樂聲音控制數據包。
(4).根據(1)的通信終端，進一步包括第二分配單元，將表示之前已通過使用無連接類型的協(xié)議發(fā)送給目標終端的音樂聲音控制數據包的歷史的歷史信息分配給通過使用無連接類型的協(xié)議發(fā)送的每個音樂聲音控制數據包。
(5).根據(2)的通信終端，進一步包括第二分配單元，將表示之前已通過使用無連接類型的協(xié)議發(fā)送給目標終端的音樂聲音控制數據包的歷史的歷史信息分配給通過使用無連接類型的協(xié)議發(fā)送的每個音樂聲音控制數據包。
(6).根據(1)的通信終端，進一步包括空數據包生成器，產生不包含命令內容的空數據包；以及感測單元，感測通過使用無連接類型的協(xié)議發(fā)送的每個音樂聲音控制數據包的產生定時，其中，當所述感測單元在預定的閾值時間之內沒有感測到音樂聲音控制數據包的產生定時時，所述發(fā)送器通過使用無連接類型的協(xié)議向目標終端發(fā)送由所述空數據包生成器產生的空數據包。
(7).根據(1)的通信終端，其中，所述數據包生成器將來自輸入的音樂聲音控制數據中的符合設置條件的音樂聲音控制數據整理成數據包，以產生音樂聲音控制數據包。
(8).根據(1)的通信終端，其中，所述面向連接類型的協(xié)議包括位于傳輸層的TCP，所述無連接類型的協(xié)議包括位于傳輸層的UDP，所述音樂聲音控制數據包括MIDI消息，所述屬于第一或第二系統(tǒng)的音樂聲音控制數據包括系統(tǒng)專用消息和其他MIDI消息，并且所述發(fā)送器通過使用TCP向目標終端發(fā)送其中系統(tǒng)專用消息被打包為數據包的音樂聲音控制數據包，通過使用UDP向目標終端發(fā)送其中其他MIDI消息被打包為數據包的音樂聲音控制數據包。
(9).一種通信終端，其中整合了面向連接類型的協(xié)議和無連接類型的協(xié)議，該通信終端包括接收器，其通過使用面向連接類型的協(xié)議接收從目標終端發(fā)送的音樂聲音控制數據包和通過使用無連接類型的協(xié)議接收從目標終端發(fā)送來的音樂聲音控制數據包；以及恢復單元，其根據表示被分配給通過使用各協(xié)議發(fā)送的所有音樂聲音控制數據包的傳輸順序的序號，并根據附加到通過使用無連接類型的協(xié)議發(fā)送的音樂聲音控制數據包的歷史信息，恢復通過使用無連接類型的協(xié)議發(fā)送的音樂聲音控制數據包。
(10).一種在使用面向連接類型的協(xié)議和無連接類型的協(xié)議的通信終端之間通信的方法，該方法包括輸入音樂聲音控制數據；將所述輸入的音樂聲音控制數據分別分類到第一和第二系統(tǒng)；將分類屬于第一或第二系統(tǒng)的音樂聲音控制數據整理成數據包以產生音樂聲音控制數據包；通過使用面向連接類型的協(xié)議發(fā)送屬于第一系統(tǒng)的音樂聲音控制數據包；通過使用無連接類型的協(xié)議發(fā)送屬于第二系統(tǒng)的音樂聲音控制數據包。
(11).一種存儲程序的計算機可讀記錄介質，使運行該程序的計算機執(zhí)行根據(10)的方法的過程。
(12).一種在使用面向連接類型的協(xié)議和無連接類型的協(xié)議的通信終端之間通信的方法，該方法包括通過使用面向連接類型的協(xié)議接收音樂聲音控制數據包和通過使用無連接類型的協(xié)議接收音樂聲音控制數據包；以及恢復單元，其根據表示被分配給通過使用各協(xié)議發(fā)送的所有音樂聲音控制數據包的傳輸順序的序號，并根據附加到通過使用無連接類型的協(xié)議發(fā)送的音樂聲音控制數據包的歷史信息，恢復通過使用無連接類型的協(xié)議發(fā)送的音樂聲音控制數據包。
(13).一種存儲程序的計算機可讀記錄介質，使運行該程序的計算機執(zhí)行根據(12)的方法的過程。
如上所述，根據本發(fā)明，無需使用諸如RTP、SDP等豐富的協(xié)議而經互聯(lián)網來有效地發(fā)送/接收MIDI消息等是可行的。


圖1是顯示根據本實施例的i會話(i-Session)系統(tǒng)的配置的圖。
圖2是說明根據該實施例的傳輸協(xié)議的圖。
圖3是說明根據該實施例流經TCP流和UDP流的TCP數據包和UDP數據包的圖。
圖4是說明根據該實施例流經TCP流和UDP流的TCP數據包和UDP數據包的另一個圖。
圖5是顯示根據該實施例的TCP數據包的配置的圖。
圖6是顯示根據該實施例的UDP數據包的配置的圖。
圖7是說明根據該實施例在單流中的恢復方法的圖。
圖8是說明根據該實施例在雙流中的恢復方法的圖。
圖9是說明根據該實施例在雙流中的恢復方法的另一個圖。
圖10是顯示根據該實施例的數據包發(fā)送處理的流程圖。
圖11是表示根據該實施例的多端口概念的圖。
圖12是表示根據該實施例的單端口概念的圖。
圖13是顯示根據該實施例的數據包接收處理的流程圖。
圖14是顯示根據該實施例的數據包接收處理的流程圖。
圖15是說明在MIDI設備之間的連接狀態(tài)的圖。
具體實施例方式
下面將介紹允許位于不同地方的多個用戶通過經互聯(lián)網發(fā)送/接收MIDI消息來實時保持會話的系統(tǒng)(以下稱“i會話系統(tǒng)”)。
A.本實施例圖1是顯示根據本實施例的i會話系統(tǒng)100的配置的圖。
i會話系統(tǒng)100由以下幾部分組成經互聯(lián)網350連接的多個播放器終端(player terminal)200-k(1≤k≤n)，連接至相應的播放器終端200-k的電子樂器300-k，和會話管理服務器400。在這種情況下，如果不需要詳細區(qū)分，則播放器終端200-k和電子樂器300-k分別被簡單地稱為播放器終端200和電子樂器300。
會話管理服務器400起到中樞地(pivotally)管理由播放器終端200實施的會話等作用。電子樂器300根據由用戶執(zhí)行的演奏操作來產生各種MIDI消息，并將產生的MIDI消息提供給作為連接目標的播放器終端200。
播放器終端(通信終端)200通過將從電子樂器300提供的MIDI消息整理成數據包而產生MIDI數據包(音樂聲音控制數據包)，然后將這些數據包發(fā)送給參與該次會話的所有播放器終端200。同時，播放器終端200接收從其他播放器終端200發(fā)送來的MIDI數據包，然后播放它們。在本實施例中，假定電子樂器300和播放器終端200分別是作為單獨的主體來提供的。但是電子樂器300和播放器終端200也可以被整體地構成，例如通過將播放器終端200的功能并入電子樂器300中。
i會話系統(tǒng)100的第一特征圖2是說明在i會話系統(tǒng)100中使用的傳輸協(xié)議的圖。根據本實施例的i會話系統(tǒng)100通過使用TCP和UDP來發(fā)送MIDI數據包，而不需使用如RTP、SDP等豐富的協(xié)議(見圖2)，TCP和UDP作為互聯(lián)網350的傳輸協(xié)議而被廣泛使用。TCP和UDP都是位于TCP/IP協(xié)議組中傳輸層的協(xié)議。這里，TCP是為了不失敗地遞送數據而具有高可靠性的協(xié)議，并且由于在其中執(zhí)行順序控制等而被稱為面向連接類型的協(xié)議。相反，UDP是具有低可靠性的協(xié)議，因為對于在路中數據包的短缺等不作出響應，并由于不執(zhí)行順序控制而被稱為無連接類型的協(xié)議，這與TCP不同。
在本實施例中，通過使用包含具有高可靠性的TCP和具有低可靠性的UDP的雙系統(tǒng)傳輸線路來發(fā)送MIDI消息。更詳細地說，播放器終端(發(fā)送器)200首先將要發(fā)送的MIDI消息分成絕對不能丟失的MIDI消息(在本實施例中，系統(tǒng)專用消息)和其他MIDI消息。根據這種分類，播放器終端(發(fā)送器)200通過使用具有高可靠性的TCP來發(fā)送系統(tǒng)專用消息，通過使用具有低可靠性的UDP來發(fā)送其他MIDI消息。
在本實施例中，示例了各種MIDI消息中僅有一種類型的MIDI消息(即系統(tǒng)專用消息)通過使用TCP來發(fā)送的情況。但是通過使用TCP來發(fā)送的MIDI消息的類型、數量等可以相應于i會話系統(tǒng)100的應用等而作出適當地變化。在下面的說明中，使用TCP的傳輸線路被稱為TCP流，以數據包的形式流經TCP流的MIDI消息被稱為TCP數據包(見圖3)。類似地，使用UDP的傳輸線路被稱為UDP流，以數據包的形式流經UDP流的MIDI消息被稱為UDP數據包(見圖3)。
i會話系統(tǒng)100的第二特征圖4是示例流經TCP流和UDP流的TCP數據包和UDP數據包的圖。
在本實施例中，如上所述，通過使用TCP流和UDP流(這些在下文中被統(tǒng)稱為“雙流”)以數據包的形式發(fā)送MIDI消息。因此，為了在接收器側通過播放器終端200來正確地播放MIDI消息，必須以正確的順序(即以傳輸順序)來處理流經每個流的數據包。在本實施例中，為了實現(xiàn)這種處理，標識傳輸順序的唯一的序號分別被分配給流經TCP流和UDP流的所有數據包，如圖4所示。接收器側的播放器終端200能夠通過按序號的順序處理各個數據包來相互同步操作。在這種情況下，因為如上所述，UDP流是具有低可靠性的傳輸線路，所以可能會造成UDP數據包丟失、UDP數據包的順序顛倒(較后發(fā)送的UDP數據包比之前發(fā)送的UDP數據包更先到達接收器側的播放器終端200，等等)及其他情形。下面描述的第三特征能夠處理這些情形。
i會話系統(tǒng)100的第三特征圖5是顯示流經TCP流的TCP數據包的配置的圖，圖6是顯示流經UDP流的UDP數據包的配置的圖。
TCP數據包包含時間戳、序號和命令段。而UDP數據包包含時間戳、第一序號、第二序號、命令段和日志段(journal section)。
在TCP數據包和UDP數據包的時間戳中，分別照原樣記述了i會話定時器(未示出)的定時器值。
在TCP數據包的序號中記述表示TCP數據包的傳輸順序的唯一的序號。類似地，在UDP數據包的第一序號中記述表示UDP數據包的傳輸順序的唯一的序號。相反，在UDP數據包的第二序號中記述已經發(fā)送了的在前的TCP數據包的序號。在這種情況下，當在前的TCP數據包不存在時(當還沒有發(fā)送TCP數據包時)，在UDP數據包的第二序號中記述序號“0”。通過采用這樣的配置，就能夠當UDP數據包丟失時適當地執(zhí)行恢復。該特征將在后面進行描述。
在TCP數據包的命令段中記述表示系統(tǒng)專用消息的命令內容。在UDP數據包的命令段中記述表示除系統(tǒng)專用消息之外的其他MIDI消息的命令內容。
在UDP數據包中提供日志段(見圖6)。在日志段中記述用于在從丟失的數據包等進行恢復時所需的歷史信息和表示被發(fā)送到該時間點為止的UDP數據包的歷史(命令內容等)(以下稱“日志”)。該日志是在上面用于MIDI的RTP有效載荷格式中引入的概念，并被用于在UDP數據包丟失時執(zhí)行恢復等等。
在這種情況下，由于用于MIDI的RTP有效載荷格式和i會話系統(tǒng)100在數據包發(fā)送方式上是不同的，因此使用日志的恢復方法也是不同的。更詳細地說，用于MIDI的RTP有效載荷格式通過僅使用UDP流(即單流)來執(zhí)行數據包傳輸，而i會話系統(tǒng)100通過使用UDP流和TCP流(雙流)來執(zhí)行數據包傳輸。因此，在兩個系統(tǒng)中恢復方法是各不相同的。然而，因為用于各恢復方法的基本概念是共同的，所以將首先說明在單流情況下的恢復方法，然后說明在雙流情況下的恢復方法。
(在單流情況下的恢復方法)圖7是說明在單流情況下的恢復方法的的圖。表示傳輸順序的序號以及表示從會話開始到該時間點所發(fā)送的UDP數據包的歷史的日志被附加到流經UDP流的每個UDP數據包上。這里，例如，如圖7中A所示，當所有的UDP數據包都以正常狀態(tài)流經UDP流時，接收器側的播放器終端200能夠通過參考分配給每個數據包的序號來正確地處理所有的UDP數據包。
相反，如圖7中B所示，當UDP數據包的一部分(序號“3”)丟失時，接收器側的播放器終端200通過參考隨后接收的UDP數據包(序號“4”)的日志來執(zhí)行對丟失的UDP數據包的恢復。更具體來講，當序號為“3”的UDP數據包在傳輸中丟失時，在接收器側的播放器終端200接收了序號為“2”的UDP數據包之后，該終端接收序號為“4”的UDP數據包(見圖7的B)。接收器側的播放器終端200判定序號為“3”的UDP數據包丟失，因為所接收的UDP數據包的序號從“2”跳到“4”。基于該判定，接收器側的播放器終端200通過參考被附加給序號為“4”的UDP數據包上的日志來執(zhí)行對序號為“3”的丟失UDP數據包的恢復處理。
例如，如果命令“降低所發(fā)出的音樂聲音(C4等)”被包含在序號為“3”的丟失UDP數據包中，那么序號為“3”的UDP數據包的命令內容被包含在序號為“4”的UDP數據包的日志中(見以上對日志的說明)。如果接收器側的播放器終端200通過分析序號為“4”的UDP數據包的日志，確定命令“降低所發(fā)出音樂聲音(C4等)”包含在序號為“3”的UDP數據包中，則該終端基于以上命令內容降低現(xiàn)在產生的音樂聲音。上述恢復處理不僅可用于UDP數據包丟失的情況，還可同樣地用于UDP數據包的順序顛倒的情況。
例如，如圖7中C所示，當在傳輸中序號為“3”的UDP數據包和序號為“2”的UDP數據包的順序顛倒時，在接收器側的播放器終端200接收到序號為“3”的UDP數據包的時間點，該終端判定序號為“2”的UDP數據包丟失。接收器側的播放器終端200基于該判定執(zhí)行與上述相同的恢復處理。以這種方式，通過使用序號為“3”的UDP數據包中的日志恢復了序號為“2”的UDP數據包。因此，即使之后序號為“2”的UDP數據包到達了，該序號為“2”的數據包也被舍棄(見圖7中C)。
在這種情況下，如果附加到UDP數據包的中日志與附加到之前的UDP數據包中的日志相同(即，要處理的命令內容沒有改變)，則即使該UDP數據包丟失，也不需要進行恢復處理，。這種情況可以通過將意思為不需要恢復處理的信息添加給UDP數據包來代替將日志附加到UDP數據包中來處理。
(在雙流情況下的恢復方法)圖8和圖9是說明在雙流中的恢復方法的圖，并與上面的圖7相對應。
在前的TCP數據包的序號和上述序號及日志一起被附加到流經UDP流的每個UDP數據包上(見圖8和圖9中括號內的數字值)。例如，如圖8中A所示，在前的TCP數據包的序號“2”還被分配給序號為“3”和“4”的各UDP數據包，而在前的TCP數據包的序號“5”還被分配給分配了序號“6”的UDP數據包。在這種情況下，為了闡明在前的TCP數據包不存在的事實，序號“0”還被分配給不具有在前的TCP數據包的UDP數據包(分配了序號“1”的UDP數據包)。當在雙流環(huán)境中所有的UDP數據包都以正常狀態(tài)流經UDP流時，與在單流環(huán)境中的情況一樣，接收器側的播放器終端200能夠通過參照被分配給每個數據包的序號來正常地處理所有的UDP數據包。
如圖8中B所示，當UDP數據包的一部分丟失時，與在單流環(huán)境中的情況一樣，接收器側的播放器終端200通過參照隨后接收到的UDP數據包的日志來執(zhí)行對丟失UDP數據包的恢復。
更具體來講，如圖8中B所示，當序號為“4”的UDP數據包丟失時，接收器側的播放器終端200在接收到序號為“3”的UDP數據包之后，該終端接收序號為“6”的UDP數據包。當接收器側的播放器終端200基于接收到的UDP數據包的序號和TCP數據包的序號，判定序號為“4”的UDP數據包丟失時，該終端通過參考附加到序號為“6”的UDP數據包上的日志(該日志在本實施例中表示序號為“1”、“3”、“4”的UDP數據包的歷史)來執(zhí)行對序號為“4”的丟失UDP數據包的恢復。而另一方面，與單流環(huán)境中的情況不同，當數據包的順序顛倒時執(zhí)行的恢復處理將如下執(zhí)行。
(模式1TCP數據包的到達提前)如圖9中C所示，當由于發(fā)生數據包的順序顛倒，數據包以如下順序到達接收器側的播放器終端200時TCP數據包(序號“2”)-UDP數據包(序號“1”)，較早到達的TCP數據包一到達該終端就立即被處理，而后到達的UDP數據包(序號“1”)被作為丟失的數據包來處理。通過使用隨后到達的UDP數據包(序號“3”)的日志來執(zhí)行對被作為丟失的數據包處理的UDP數據包的恢復。
(模式2TCP數據包的到達延遲)如圖9中D所示，當由于發(fā)生數據包的順序顛倒，數據包以如下順序到達接收器側的播放器終端200時UDP數據包(序號“3”)-TCP數據包(序號“2”)，較早到達的UDP數據包被暫時保存在緩沖器等之中，并且直到被延遲的TCP數據包到達該終端才開始處理。如上所述，為了判定TCP數據包的到達是否延遲，將本應該比相關數據包更早被處理的在前的TCP數據包的序號添加到每個UDP數據包。接收器側的播放器終端200通過參考被添加到相關UDP數據包的在前TCP數據包的序號，判定相關UDP數據包的處理是否應該被延遲。當在前的TCP數據包沒有到達時，相關UDP數據包的處理被延遲，直到延遲的TCP數據包到達該終端。通過以上處理，實現(xiàn)了雙流環(huán)境中的恢復方法。
i會話系統(tǒng)100的第四特征在被用于感測發(fā)送器側的播放器終端200和接收器側的播放器終端200之間的通信是否斷開的配置方面，i會話系統(tǒng)100也具有特征。
更詳細來講，在通信期間，發(fā)送器側的播放器終端200每一秒向接收器側的播放器終端200發(fā)送至少一個數據包。發(fā)送器側的播放器終端200總是感測數據包產生定時。當發(fā)送器側生成器的播放器終端(空數據包生成器)200感測到在預定的閾值時間內(例如，在1秒內)沒有數據包被產生/發(fā)送時，該終端產生其命令段為空的數據包(換言之，不包含命令內容的空數據包)，然后將該數據包發(fā)送到接收器側的播放器終端200。在這種情況下，該包的日志段不是空的，而且在日志段中記述直到該時間點為止已被發(fā)送的UDP數據包的日志。
而另一方面，當接收器側的播放器終端200在預定的時間(例如3秒)之內沒有接收到UDP數據包時，該終端認為與發(fā)送器側的播放器終端200的通信斷開。
當采用前面的配置時，即使沒有從發(fā)送器側的終端發(fā)送活動感測消息(被發(fā)送的用于防止當MIDI電纜斷開時在接收器側的終端聲音一直鳴響的信息)，接收器側的終端也能夠判定上述通信是否斷開，，這與現(xiàn)有技術不同。以這種方式，通過去除發(fā)送器側的終端中的活動感測消息，TCP/IP通信中的帶寬能夠被有效地使用。這里，在上面的例子中定義的時間等(例如，最小時間間隔，在該間隔內從發(fā)送器側的播放器終端200發(fā)送UDP數據包，等等)可以相應于i會話系統(tǒng)100的設計等而作適當地改變。
將參考圖10至圖14和下面的其他內容來說明實現(xiàn)該i會話系統(tǒng)100的每個播放器終端200的操作。
數據包發(fā)送操作圖10是顯示由每個播放器終端200的MIDI發(fā)送部分執(zhí)行的數據包發(fā)送處理的流程圖。MIDI發(fā)送部分提供如下功能將從連接的電子樂器等提供的MIDI消息整理成數據包，然后將該消息發(fā)送到參與該會話的所有播放器終端200。通過協(xié)同操作被整合到各播放器終端200中的硬件資源(通信設備、CPU、存儲器，等等)和被存儲在存儲器中的軟件來實現(xiàn)該MIDI發(fā)送部分。
當經MIDI驅動器(未示出)從電子樂器接收到MIDI消息時，MIDI發(fā)送部分(輸入單元)從接收的MIDI消息中除去未進入TCP流和UDP流的MIDI消息(即，未進入雙流的MIDI消息)(步驟S1-＞步驟S2)。在這種情況下，例如，定時時鐘、活動感測消息、關閉所有音符(all-note-off)消息、利用運行狀態(tài)的消息等可能被列為除去的MIDI消息?？梢韵鄳趇會話系統(tǒng)100的應用等，適當地設置/改變哪些MIDI消息應該被除去以及哪些MIDI消息應該被整理成數據包(即設置條件)。
在MIDI發(fā)送部分通過如上所述除去沒有進入雙流的MIDI消息而僅提取出進入雙流的MIDI消息(即符合設置條件的MIDI消息)之后，該部分根據由指令設備(未示出)給出的端口分配命令將MIDI消息分發(fā)給多個端口(步驟S3)?，F(xiàn)在，在本實施例中，假定的是其中定義了多個可用端口的多端口(見圖11)。但是其中使用一個端口的單端口(見圖12)也同樣可以采用。
在MIDI發(fā)送部分執(zhí)行了這樣的分發(fā)之后，該部分通過參考i會話定時器將臨時時間戳附加到分配給每個端口的每個MIDI消息上，然后在由每個端口提供的每個MIDI消息緩沖器(未示出)中順序存儲這些消息(步驟S4-＞步驟S5)。然后，MIDI發(fā)送部分從MIDI消息緩沖器中收集得到一個數據包的MIDI消息(步驟S6)。在這種情況下，由于來自MIDI消息的系統(tǒng)專用消息不能與其他MIDI消息一起同時發(fā)送，MIDI發(fā)送部分分別收集得到系統(tǒng)專用消息和其他MIDI消息。這里，響應i會話系統(tǒng)100的應用等來適當地設置被打包到一個數據包中的MIDI消息的數據量。
然后，當獲得的MIDI消息是除系統(tǒng)專用消息之外的MIDI消息(以下稱“其他MIDI消息”)時，MIDI發(fā)送部分(數據包生成器)判定該消息應該被放到UDP流上來發(fā)送，然后通過將獲得的其他MIDI消息整理成數據包來產生UDP數據包(步驟S7-＞步驟S8)。MIDI發(fā)送部分(第一分配單元和第二分配單元)將表示UDP數據包的傳輸順序的序號和被分配給在前的TCP數據包的序號分配給以這種方式產生的UDP數據包，然后添加表示直到現(xiàn)在所發(fā)送的UDP數據包的歷史的日志(步驟S9-＞步驟S10)。然后，MIDI發(fā)送部分(發(fā)送器)將添加了序號和日志的數據包發(fā)送到參與該會話的所有播放器終端200(步驟S11)。然后，處理結束。
而另一方面，當獲得的MIDI消息是系統(tǒng)專用消息時，MIDI發(fā)送部分(數據包生成器)判定該消息應該被放到TCP流上來發(fā)送，然后劃分該消息以將獲得的系統(tǒng)專用消息包含在一個數據包中，然后產生TCP數據包(步驟S7-＞步驟S12-＞步驟S13)。在MIDI發(fā)送部分(發(fā)送器)以這種方式產生包含系統(tǒng)專用消息的TCP數據包之后，該部分分配表示TCP數據包的傳輸順序的序號(步驟S14)，然后將該數據包發(fā)送到參與該會話的所有播放器終端200(步驟S11)。然后，處理結束。
數據包接收操作圖13和圖14是顯示由每個播放器終端200的MIDI接收部分執(zhí)行的數據包接收處理的流程圖。這里，MIDI接收部分提供以下功能將從其他播放器終端200發(fā)送的數據包復原為MIDI消息并在適當的定時合并由復原的MIDI消息指示的命令。如同MIDI發(fā)送部分，通過協(xié)同操作被整合到各播放器終端200中的硬件資源(通信設備、CPU、存儲器，等等)和被存儲在存儲器中的軟件來實現(xiàn)MIDI接收部分。
當MIDI接收部分(接收器)經互聯(lián)網350等從其他播放器終端200接收數據包時，該部分判定所接收的數據包是UDP數據包還是TCP數據包(步驟Sa1-＞步驟Sa2)。當MIDI接收部分確定所接收的數據包是UDP數據包時，該部分將UDP數據包暫且存儲在緩沖器中(步驟Sa2-＞步驟Sa3)。暫且將所接收的數據包存儲在緩沖器中的原因是在本應該較早到達的TCP數據包沒有到達等情況下，UDP數據包的處理必須被延遲，直到TCP數據包到達。
MIDI接收部分(恢復單元)檢查分配給UDP數據包的序號、分配給直到現(xiàn)在所接收到的TCP數據包的序號，等等，然后分析添加到UDP數據包的日志等(步驟Sa4)。如果MIDI接收部分(恢復單元)根據分析結果判定恢復處理是需要的(步驟Sa5是)，該部分通過使用日志等來執(zhí)行恢復處理以重新產生丟失的UDP數據包(步驟Sa6)。在這種情況下，由于上面描述了恢復處理的細節(jié)，因此省略了對該處理的說明。
在MIDI接收部分執(zhí)行了恢復處理之后，該部分將指示應當執(zhí)行時間的時間戳附加到MIDI消息上，然后存儲在MIDI命令隊列中(步驟Sa7-＞步驟Sa8)。
而另一方面，如果MIDI接收部分判斷從其他播放器終端200接收的數據包是TCP數據包時，則MIDI接收部分判斷該TCP數據包中包含的系統(tǒng)專用消息是否已被劃分(步驟Sa2-＞步驟Sa12)。如果MIDI接收部分判斷該消息已被劃分，則通過使用被劃分的每個系統(tǒng)專用消息，恢復事先劃分的系統(tǒng)專用消息(步驟Sa13)。然后，MIDI接收部分將待執(zhí)行時間的時間戳添加到恢復后的系統(tǒng)專用消息中，并將其存儲到專門的系統(tǒng)專用消息緩沖器(未示出)(步驟Sa14-＞步驟Sa15)。
如果在MIDI命令隊列或者系統(tǒng)專用消息緩沖器中存儲所接收的MIDI消息，則MIDI接收部分從存儲在所述MIDI命令隊列或者系統(tǒng)專用消息緩沖器中的全部MIDI消息中選擇應該被最先處理的MIDI消息，并將其抽取出。然后，MIDI接收部分將被附加給所取出的MIDI消息的時間戳與i會話計時器(未示出)所示出的時間進行比較，以判斷是否到達該事件的處理定時(步驟Sa10)。當進行在步驟Sa10期間重復執(zhí)行到達處理定的確定時，MIDI接收部分執(zhí)行適當的MIDI消息處理(步驟Sa11)，并且通過將該事件所示出的MIDI命令傳送到MIDI驅動器來結束處理。所述的MIDI命令被從MIDI驅動器送往音響(未示出)，從而基于該MIDI命令來產生音樂。
如上所述，根據本實施例，參與會話的每個播放器終端能夠使用現(xiàn)有的TCP和UDP來有效地發(fā)送/接收MIDI數據包，而無需實施諸如RTP、RTCP和SDP等豐富的協(xié)議。
通過以上述方式設置被TCP數據包和UDP數據包中所采用的序號和日志，能夠通過支持雙流的簡單方法來恢復丟失的數據包。
由于根據本實施例的播放器終端200的功能可以通過計算機程序來執(zhí)行，該程序能夠經由存儲該程序的計算機可讀記錄介質(CD-ROM等)和通信網絡(互聯(lián)網等)來散布。當然，能夠用其中安裝有執(zhí)行上述功能的CPU、ROM等的專用設備來構成播放器終端200。
權利要求
1.一種整合了面向連接類型的協(xié)議和無連接類型的協(xié)議的通信終端，該通信終端包括輸入單元，其輸入音樂聲音控制數據；數據包生成器，將所述輸入的音樂聲音控制數據分別分類到第一和第二系統(tǒng)，并將分類屬于第一或第二系統(tǒng)的音樂聲音控制數據整理成數據包以產生音樂聲音控制數據包；以及發(fā)送器，通過使用面向連接類型的協(xié)議將屬于第一系統(tǒng)的音樂聲音控制數據包發(fā)送到目標終端，并通過使用無連接類型的協(xié)議將屬于第二系統(tǒng)的音樂聲音控制數據包發(fā)送到目標終端。
2.根據權利要求1的通信終端，進一步包括第一分配單元，其將表示傳輸順序的序號分配給通過使用面向連接類型的協(xié)議或無連接類型的協(xié)議發(fā)送的所有音樂聲音控制數據包。
3.根據權利要求2的通信終端，其中，所述第一分配單元將用于標識音樂聲音控制數據包的序號和已分配給在前的音樂聲音控制數據包的序號分配給通過使用無連接類型的協(xié)議發(fā)送的每個音樂聲音控制數據包，其中所述在前的音樂聲音控制數據包已通過使用面向連接類型的協(xié)議發(fā)送。
4.根據權利要求1的通信終端，進一步包括第二分配單元，將歷史信息分配給通過使用無連接類型的協(xié)議發(fā)送的每個音樂聲音控制數據包，該歷史信息表示之前通過使用無連接類型的協(xié)議發(fā)送到目標終端的音樂聲音控制數據包的歷史。
5.根據權利要求2的通信終端，進一步包括第二分配單元，將歷史信息分配給通過使用無連接類型的協(xié)議發(fā)送的每個音樂聲音控制數據包，所述歷史信息表示之前通過使用無連接類型的協(xié)議發(fā)送到目標終端的音樂聲音控制數據包的歷史。
6.根據權利要求1的通信終端，進一步包括空數據包生成器，產生不包含命令內容的空數據包；以及感測單元，感測通過使用無連接類型的協(xié)議發(fā)送的每個音樂聲音控制數據包的產生定時，其中，當所述感測單元在預定的閾值時間之內沒有感測到音樂聲音控制數據包的產生定時時，所述發(fā)送器通過使用無連接類型的協(xié)議向目標終端發(fā)送由所述空數據包生成器產生的空數據包。
7.根據權利要求1的通信終端，其中，所述數據包生成器將來自輸入的音樂聲音控制數據中的符合設置條件的音樂聲音控制數據整理成數據包，以產生音樂聲音控制數據包。
8.根據權利要求1的通信終端，其中，所述面向連接類型的協(xié)議包括位于傳輸層的TCP，所述無連接類型的協(xié)議包括位于傳輸層的UDP，所述音樂聲音控制數據包括MIDI消息，所述屬于第一或第二系統(tǒng)的音樂聲音控制數據包括系統(tǒng)專用消息和其他MIDI消息，并且所述發(fā)送器通過使用TCP向目標終端發(fā)送其中系統(tǒng)專用消息被打包為數據包的音樂聲音控制數據包，通過使用UDP向目標終端發(fā)送其中其他MIDI消息被打包為數據包的音樂聲音控制數據包。
9.一種整合了面向連接類型的協(xié)議和無連接類型的協(xié)議通信終端，該通信終端包括接收器，其通過使用面向連接類型的協(xié)議接收從目標終端發(fā)送的音樂聲音控制數據包和通過使用無連接類型的協(xié)議接收從目標終端發(fā)送的音樂聲音控制數據包；以及恢復單元，其根據表示被分配給通過使用各協(xié)議發(fā)送的所有音樂聲音控制數據包的傳輸順序的序號，并根據被附加到通過使用無連接類型的協(xié)議發(fā)送的音樂聲音控制數據包中的歷史信息，恢復通過使用無連接類型的協(xié)議發(fā)送的音樂聲音控制數據包。
10.一種在使用面向連接類型的協(xié)議和無連接類型的協(xié)議的通信終端之間通信的方法，該方法包括輸入音樂聲音控制數據；將所述輸入的音樂聲音控制數據分別分類到第一和第二系統(tǒng)；將分類屬于第一或第二系統(tǒng)的音樂聲音控制數據整理成數據包以產生音樂聲音控制數據包；通過使用面向連接類型的協(xié)議發(fā)送屬于第一系統(tǒng)的音樂聲音控制數據包；和通過使用無連接類型的協(xié)議發(fā)送屬于第二系統(tǒng)的音樂聲音控制數據包。
11.一種存儲程序的計算機可讀記錄介質，所述程序使運行該程序的計算機執(zhí)行根據權利要求10的方法的過程。
12.一種在使用面向連接類型的協(xié)議和無連接類型的協(xié)議的通信終端之間通信的方法，該方法包括通過使用面向連接類型的協(xié)議接收音樂聲音控制數據包，并通過使用無連接類型的協(xié)議接收音樂聲音控制數據包；以及恢復單元，其根據表示被分配給通過使用各協(xié)議發(fā)送的所有音樂聲音控制數據包的傳輸順序的序號，并根據被附加到通過使用無連接類型的協(xié)議發(fā)送的音樂聲音控制數據包中的歷史信息，恢復通過使用無連接類型的協(xié)議發(fā)送的音樂聲音控制數據包。
13.一種存儲程序的計算機可讀記錄介質，所述程序使運行該程序的計算機執(zhí)行根據權利要求12的方法的過程。
全文摘要
采用被廣泛用作傳輸協(xié)議的TCP和UDP來作為用于發(fā)送MIDI消息的協(xié)議。發(fā)送器側的播放器終端將發(fā)送的MIDI消息分類為絕對不應丟失的系統(tǒng)專用消息和其他MIDI消息。發(fā)送器側的播放器終端通過使用具有高可靠性的TCP來發(fā)送系統(tǒng)專用消息，通過使用具有低可靠性的UDP來發(fā)送其他MIDI消息。
文檔編號G06F13/00GK1661989SQ20051000910
公開日2005年8月31日 申請日期2005年2月4日 優(yōu)先權日2004年2月4日
發(fā)明者多田幸生 申請人:雅馬哈株式會社