其他

文章目錄 1.語音採集2.編碼3.網路傳送4.解碼5.語音播放2.雜訊抑制 DENOISE3.抖動緩衝區 JitterBuffer4.靜音檢測 VAD5.混音演算法       當我們使用像Skype、QQ這樣的工具和朋友流暢地進行語音視訊交談時，我們可曾想過其背後有哪些強大的技術在支撐？本文將對網路語音通話所使用到的技術做一些簡單的介紹，算是管中窺豹吧。一.概念性模型      網路語音通話通常是雙向的，就模型層面來說，這個雙向是對稱的。

 在上一篇裡面，我們初步瞭解了OO設計，OO設計的最獨特之處在於他看待需求的方式。用這樣的方式，我們不需要急於確定軟體需要實現哪些流程、設計哪些功能點、製作哪些畫面，而是要關注需求中一些更加基本的概念。首先根據這些概念開發出一些零件，然後把這些零件組裝起來實現需要的功能。用這樣的方式，我們不需要一開始就去知道所有的業務需求，只需要知道一些比較重要的需求，就可以開始開發了。這樣開發出來的程式不僅可以實現當前的需要，同時也是一個業務開發的平台，在這個平台上可以不斷的開發新的功能。這種設計思想有很多實

 一.緣起       最近做一個服務端程式，系統運行時，在特定的時候會啟動一個通知線程，通知線程執行的方法經簡化後就是如下的FirstStateNotifyThread： AutoResetEvent autoResetEvent = new AutoResetEvent(false); private void FirstStateNotifyThread() { this.logger.LogWithTime("進入通知線程");

             應用情境：net 架構下的HttpModule (.net2.0 代碼)         先看一下 Observer 模式結構圖:      再看一下.net架構中的應用結構圖   

NET架構中的 Decorator 和 Strategy 模式        應用情境：net 架構下的TextWriter，HtmlTextWriter，CssTextWriter,IndentedTextWriter 等        先看一下Decorator 模式結構圖:    NET 下的 Decorator 模式(TextWriter及其衍生類別):    雖然圖形有所不同，但大致結構相似。    這裡就大概先分析一下吧。    TextWriter 作為 一個抽象類別定義形式如下:

      隨著互連網越來越普及，以及物聯網的興起，IPv4地址已遠遠不夠用，IPv6的普及將是不可避免的趨勢。以前，我們的大部分socket程式幾乎都是針對IPv4而開發，如果不做升級重構，那麼使用IPv6地址的用戶端將無法使用服務端提供的服務。如何才能像ESFramework一樣，使服務端和用戶端都可以同時支援IPv6了？使我們的P2P打洞也相容IPv6了？下面我們將要點一一點出。     

就現在經濟大環境而言，很不樂觀，程式員的日子也很不好過，無論是還在找工作的、還是已經入職多年、哪怕做到專案經理技術經理的，壓力都異常巨大，似乎處處充滿危機。但是，仔細分析一下，出路還是有的，甚至解決溫飽、過上有房有車沒貸款的生活也是很可能的。首先，在如今這個浮躁的社會，大多數人的心態也是浮躁的，只要你能潛下心來，深入研究某個技術，有了一技之長，溫飽問題肯定就可以先解決了。1.一技之長新技術層出不窮，而核心的精髓的東西卻變化不大，就像.NET，從VS2003到VS2012，已經有10個年頭，VS的

        Factory 模式是一種非常基本同時也是被廣泛使用的設計模式, 我在這裡就不多說了，這種模式在架構程式設計中經常被採用，今天就說一下在.NET 架構下的一個使用例子。首先請大家看一下如下程式碼片段：int iCount = System.Text.Encoding.Default.GetByteCount(calStr.Trim());.....byte[] b = Encoding.Default.GetBytes(str);.....Encoding encode =

    由於最近有了寶寶，導致夜裡寫文章的時間越來越短，而白天又忙於開發。沒辦法，只有擠時間去寫東西了。前些天在園子裡看到了這篇文章，http://www.cnblogs.com/Yahong111/archive/2007/07/18/822946.html，對裡面寫的內容瀏覽了一下，這裡首先對作者的實踐精神表示讚賞。我這裡只是從別的角度闡述一下AbstractFactory在這種應用情境下的發展，內容不多，希望大家見諒。    1. DbService

      在很多軟體系統中，都允許使用者佈建自己的頭像，甚至可以直接使用網路攝影機照相作為自己的頭像，就像QQ的自拍頭像功能一樣。            這種功能是如何?的了？最直接的，我們可以使用Windows提供的VFW技術或DirectX技術來捕獲網路攝影機採集到的視頻和圖片。但是，無論使用這兩種技術中的哪一個，要實現一個相容所有網路攝影機而又運行穩定的拍照功能，都不是那麼容易。幸運的是，OMCS已經內建整合了這種功能的一個WinForm控制項PhotoPanel，我們可以直接拿來使用。

文章目錄 1.同步廣播模式2.非同步廣播模式       在開發類似視訊交談的應用時，我們經常需要擷取網路攝影機的相關資訊；而在進行視訊交談時，我們可能還希望有一些動態能力。比如，在不中斷視訊交談的情況下，切換一個網路攝影機、或者修改網路攝影機採集的解析度或編碼品質等等。OMCS提供了很多有用的特性以支援上述需求。一.枚舉網路攝影機      我們如何得知當前的電腦有哪些網路攝影機了？     

      近段時間，有幾個朋友問我如何?類似QQ離線檔案的功能。不想一一作答，就寫一篇博文來比較完整的解釋這個問題。      所謂“離線檔案”，就是當接收者不線上時，寄件者先把檔案傳送給服務端，在伺服器上暫時儲存，等接收者上線時，服務端再把檔案發送給他。當然，要想實現離線檔案的功能，其最基本的前提是要先實現傳送檔案的功能，我們就以ESFramework提供的傳送檔案的功能為基礎，在其之上一步步完成一個基本的離線檔案功能。      下面我們就使用者在使用離線檔案時，按各個動作發生的先後順序，

     在一些軟體系統中，需要用到手寫塗鴉的功能，然後可以將塗鴉的結果儲存為圖片，並可以將“真跡”通過網路發送給對方。這種手寫塗鴉功能是如何?的了？最直接的，我們可以使用Windows提供的GDI技術或GDI+技術來實現繪圖功能。但是，要實現一個如此簡單的塗鴉板，也不是那麼容易的事情。幸運的是，我們可以直接使用OMCS提供的內建整合了這種功能的一個WinForm控制項HandwritingPanel。      HandwritingPanel控制項的主要介面如所示： /// &

      當同一個系統的兩個用戶端A、B相互發送訊息給對方時，如果它們之間存在P2P通道，那麼訊息傳送的路徑就有兩種：直接經P2P通道傳送、或者經伺服器中轉。如所示：           通常就一般應用而言，如果P2P通道能夠成功建立（即所謂的打洞成功），A和B之間的所有訊息將直接走P2P通道，這樣可以有效節省伺服器的頻寬和降低伺服器的負載。這種模型即是所謂的“P2P通道優先”模型，也是最簡單的通道選擇模型。一.通道品質優先模型      然而，有些系統可能不能就如此簡單的處理，最簡單的例子，

      C和C++有很多好的類庫的沉澱，在.NET中，完全拋棄它們而重頭再來是非常不明智的、也是不現實的，所以，我們經常需要通過Pinvoke來使用以前遺留下來的非託管的dll。就.NET中使用非託管的dll經驗而言，經常碰到的問題至少有兩個，它們都是通過在運行時拋出異常來體現的。1.試圖載入格式不正確的程式      出現這種異常，通常是.NET應用程式的“目標平台”與非託管dll的平台不一樣。      一般，在使用VS開發.NET的應用程式和類庫時，預設的目標平台為“Any CPU”，

《大話設計模式》將於11月底由清華大學出版社出版 《大話設計模式》第29章-OOTV杯超級模式大賽—模式總結（一） 《大話設計模式》第29章-OOTV杯超級模式大賽—模式總結（二）《大話設計模式》第29章-OOTV杯超級模式大賽—模式總結（三）《大話設計模式》第29章-OOTV杯超級模式大賽—模式總結（四） 《大話設計模式》第29章-OOTV杯超級模式大賽—模式總結（五） 《大話設計模式》第29章-OOTV杯超級模式大賽—模式總結（六）（接上一篇）  29.9  夢醒時分時間：7月23日 晚上

 （續上篇）         小菜學會了反射後，正在興奮，想著大鳥的問題。此時，突然聲音響起。      “死了都要愛，不淋漓盡致不痛快，感情多深只有這樣，才足夠表白。死了都要愛……”       原來是小菜的手機鈴聲，大鳥嚇了一跳，說道：”你小子，用這歌做鈴聲，嚇唬人啊！這要是在公司開大會時響起，你要被領導淋漓盡致愛死！MD，還在唱，快接！”       小菜很是鬱悶，拿起手機一看，一個美女來的電話，由轉，馬上接通了手機，“喂！”     

        話說三國時期，曹操帶領百萬大軍攻打東吳，大軍在長江赤壁駐紮，軍船連成一片，眼看就要滅掉東吳，統一天下，曹操大悅，於是大宴眾文武，在酒席間，曹操詩性大發，不覺吟道：“喝酒唱歌，人生真爽。…………”。眾文武齊呼：“丞相好詩！”於是一臣子速命印刷工匠刻版印刷，以便流傳天下。         樣張出來給曹操一看，曹操感覺不妥，說道：“喝與唱，此話過俗，應改為‘對酒當歌’較好！”，於是此臣就命工匠重新來過。工匠眼看連夜刻版之工，徹底白費，心中叫苦不喋。只得照辦。              

我們設想一下網路視頻會議的情境：在一個視頻會議虛擬房間中，每個人都需要將自己的視頻資料發送給房間中的其它人，從而實現在同一個地方進行即時會議的效果。為了簡單起見，我們假設，這個虛擬視頻會議房間中只有三個人，其結構可以簡化描繪如下： 　　用戶端A需要將自己的視頻資料發送給B和C，用戶端B需要發給A和C，用戶端C需要發給A和B。有了這個情境基礎，接下來，我們將從資料傳送通道的角度來分析在這個模型中可以採用的通道方式，以及進行對比並找出最優的通道模型。所謂最優，就是伺服器所佔用的頻寬（包括上行和下行）