Development of a Multipurpose Audio Transmission System   on the Internet   Takashi Kishida Graduate School of Information...
Overview <ul><li>Introduction   </li></ul><ul><li>Purpose </li></ul><ul><li>Audio communication scenes </li></ul><ul><li>I...
Background Spreading Broadband networks ―   Real-time audio transmission is popular Various types of audio communications ...
A problem in the Audio Transmission   <ul><li>Considerations in audio communication scenes </li></ul><ul><ul><li>Robustnes...
Purpose <ul><li>Consideration on conditions of requirements for each audio communication scenes </li></ul><ul><li>Developm...
Classification Requirements Low High Very High Synchronization Reliable  transmission Smooth interaction Audio synchroniza...
Audio Communication Scenes Distance Chorus Distance Lecture Audio conference Conversation 100ms 400ms End-to-end delay Low...
MRAT(Multipurpose RAT) <ul><li>MRAT was developed on the basis of RAT </li></ul><ul><ul><li>RAT(Robust Audio Tool) is one ...
Relation of Audio Communication Scenes and modes of MRAT Distance Chorus Distance Lecture Audio conference Conversation 10...
Chorus mode <ul><li>We tuned buffering parameters of an audio device.  </li></ul>To realize delays less than about 100ms ー...
Read length variation This elapsed time related to delays. The longer elapsed time is, the longer delays are.
Evaluation of cushion Cushion is close related to buffering time and defined by elapsed time. (Cushion + An additional pro...
Broadcast mode <ul><li>To achieve robustness </li></ul><ul><ul><li>We use Reed-Solomon block code </li></ul></ul><ul><ul><...
FEC with Reed-Solomon code Reed-Solomon ( 15,12 )  block code ・・・ 15 packets 12 packets Audio data packet 3 packets Redund...
State of Implementation <ul><li>All modes are completed </li></ul><ul><li>Almost all audio codec are implemented in Broadc...
Evaluations of MRAT <ul><li>Measurement of delays on each mode </li></ul><ul><li>FEC Performance measurement of Broadcast ...
Experimental environment on delays Ethernet 100Mbps Host A Host B Transmit Recording PC Metronome CPU PentiumⅢ 600MHz OS  ...
Measurement of delays These values are almost same as processing delay. Transfer delay in practical networks is added. The...
FEC Performance measurement of Broadcast mode Ethernet 100Mbps Loss generator Host A Host B CPU PentiumⅢ   600MHz OS  Vine...
Result (15 , 13) (15 , 12) (15 , 11) The theoretical values and the experimental values are almost the same. Packet loss r...
Result (15 , 13) (15 , 12) (15 , 11) Packet loss 11 %  non-FEC Using RS-FEC(15,11) 10 12 ~ ~ ~ ~
Distance Seminar using Broadcast mode Hiroshima City Univ. Hiroshima Univ. Saga Univ. Experimental IP Network (ATM 45Mbps)...
Error recovery of packet losses using Broadcast mode The results of error recovery for only 100 seconds as a typical part ...
Distance  Chorus Hiroshima City Univ. Hakushima Elementary School ( Main melody ) Minami-Kanon Elementary ( Sub melody ) E...
Conclusion <ul><li>Classification of audio communication scenes </li></ul><ul><li>Development of a multipurpose audio tran...
Future Problems <ul><li>New applications using each mode </li></ul><ul><li>Dynamic and adaptive changing of three modes de...
Scalability of Distance Chorus <ul><li>How wide area to realize distance chorus? </li></ul><ul><li>Light propagation: 2100...
Bandwidth of MRAT 66 ○ 52.8 GSM 160 × 128 VDVI 160 ○ 128 DVI 80 ○ 64 G726-40 120 ○ 96 G726-40 160 ○ 128 G726-40 200 ○ 160 ...
The quality of sound comparison of MRAT and RAT This is the result that the noise of MRAT and RAT was measured.  FFT was u...
To realize the Distance Chorus accompaniment Main melody Sub melody Ideal tolerant delay 70ms
Study of burst errors <ul><li>We use Reed-Solomon (15,11) code </li></ul>It could be almost recovered at distance seminar....
End-to-end delay bounds 150ms Delay not Perceived In most cases 400ms “ Natural” Interaction ITU-T G.114 ITU-T G.114 150ms...
Where can you download? <ul><li>You can get MRAT here  </li></ul><ul><li>http://www.mame.csi2.net/mrat/frame.html </li></u...
Upcoming SlideShare
Loading in …5
×

Development of a Multipurpose Audio Transmission System on the Internet

662 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
662
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • I would like to present our paper entitled &amp;quot;Development of a Multipurpose Audio Transmission System on the Internet&amp;quot;.
  • Development of a Multipurpose Audio Transmission System on the Internet

    1. 1. Development of a Multipurpose Audio Transmission System on the Internet Takashi Kishida Graduate School of Information Sciences, Hiroshima City University, Japan
    2. 2. Overview <ul><li>Introduction </li></ul><ul><li>Purpose </li></ul><ul><li>Audio communication scenes </li></ul><ul><li>Implementation </li></ul><ul><li>Evaluations </li></ul><ul><li>Conclusion </li></ul>
    3. 3. Background Spreading Broadband networks ―   Real-time audio transmission is popular Various types of audio communications have been attempted. ―   Distance lecture, Distance chorus etc. We should consider requirements depending on each scene.
    4. 4. A problem in the Audio Transmission <ul><li>Considerations in audio communication scenes </li></ul><ul><ul><li>Robustness </li></ul></ul><ul><ul><ul><li>Reliability audio transmission </li></ul></ul></ul><ul><ul><ul><li>An ability to recover packet losses on networks </li></ul></ul></ul><ul><ul><li>Short delay </li></ul></ul><ul><ul><ul><li>End-to-end delays include processing delays of an end node and transfer delays on a network </li></ul></ul></ul>Trade-off between robustness and delays Difficulty to realize both requirements at the same time Ex.) the case of about 150 ms delays
    5. 5. Purpose <ul><li>Consideration on conditions of requirements for each audio communication scenes </li></ul><ul><li>Development of a multipurpose audio transmission system to adapt to various scenes </li></ul>
    6. 6. Classification Requirements Low High Very High Synchronization Reliable transmission Smooth interaction Audio synchronization (Short delay) Main requirement High Middle Low Robustness Any Less than 400ms ITU-T G.114 Less than 100 ms Allowable delay One to many Many to many Many to many Direction Distance lecture Audio conference Distance chorus Scenes
    7. 7. Audio Communication Scenes Distance Chorus Distance Lecture Audio conference Conversation 100ms 400ms End-to-end delay Low High 0ms Robustness
    8. 8. MRAT(Multipurpose RAT) <ul><li>MRAT was developed on the basis of RAT </li></ul><ul><ul><li>RAT(Robust Audio Tool) is one of mbone tools. </li></ul></ul><ul><li>MRAT has three modes to adapt to various scenes </li></ul><ul><ul><li>Chorus mode </li></ul></ul><ul><ul><li>  ・・・ shorter delays </li></ul></ul><ul><ul><li>Conversation mode </li></ul></ul><ul><ul><li>Broadcast mode </li></ul></ul><ul><ul><li>・・・ high robustness </li></ul></ul>
    9. 9. Relation of Audio Communication Scenes and modes of MRAT Distance Chorus Distance Lecture Audio conference Conversation 100ms 400ms End-to-end Delay Low High 0ms Robustness Original RAT Shorter delays High robustness Chorus mode Conversation mode Broadcast mode These two modes are added.
    10. 10. Chorus mode <ul><li>We tuned buffering parameters of an audio device. </li></ul>To realize delays less than about 100ms ー This mode is set up as to achieve shorter delay
    11. 11. Read length variation This elapsed time related to delays. The longer elapsed time is, the longer delays are.
    12. 12. Evaluation of cushion Cushion is close related to buffering time and defined by elapsed time. (Cushion + An additional processing delay = 70 ms) Cushion was decreased to about 26 ms from 90 ms by changing parameters. MRAT realizes delays of 70ms.
    13. 13. Broadcast mode <ul><li>To achieve robustness </li></ul><ul><ul><li>We use Reed-Solomon block code </li></ul></ul><ul><ul><li>Reed-Solomon block code has advantage in burst errors </li></ul></ul><ul><li>  FEC ( Forward Error Correction ) </li></ul>ー Broadcast mode is set up as to achieve robustness. Advantage in a real-time application sender receiver <ul><ul><li>generating redundant packet each some packets </li></ul></ul><ul><ul><li>recovery from redundant packets in the case of packet losses </li></ul></ul>
    14. 14. FEC with Reed-Solomon code Reed-Solomon ( 15,12 ) block code ・・・ 15 packets 12 packets Audio data packet 3 packets Redundant packet Header data Transmit This code has an ability of recovery from less than 3 packets lost.
    15. 15. State of Implementation <ul><li>All modes are completed </li></ul><ul><li>Almost all audio codec are implemented in Broadcast mode </li></ul><ul><li>Confirmation of implementation </li></ul>SoundBlaster Live! Value Soundcard Vine Linux 2.1,Vine Linux2.1.5,Vine Linux2.5 OS PentiumⅢ 1.0GHz ~ PentiumⅡ300MHz CPU
    16. 16. Evaluations of MRAT <ul><li>Measurement of delays on each mode </li></ul><ul><li>FEC Performance measurement of Broadcast mode </li></ul><ul><li>Practical experiments </li></ul><ul><ul><li>Distance Chorus using Chorus mode </li></ul></ul><ul><ul><li>Distance seminar using Broadcast mode </li></ul></ul>
    17. 17. Experimental environment on delays Ethernet 100Mbps Host A Host B Transmit Recording PC Metronome CPU PentiumⅢ 600MHz OS Vine Linux2.5 CPU PentiumⅢ   1GHz OS Vine Linux2.1 Record Record We measured the difference of delays between (a) and (b). (a) Sound of metronome (b) Sound via Host B
    18. 18. Measurement of delays These values are almost same as processing delay. Transfer delay in practical networks is added. These satisfy all conditions of the defined delay in each mode 72 [ms] 132 [ms] 138 [ms] 138 [ms] 143 [ms] Delays Less than 100 [ms] Less than 400 [ms] any any any Defined delay Chorus Conversation Broadcast (15,13) Broadcast (15,12) Broadcast (15,11) Mode
    19. 19. FEC Performance measurement of Broadcast mode Ethernet 100Mbps Loss generator Host A Host B CPU PentiumⅢ   600MHz OS Vine Linux2.5 CPU PentiumⅢ   1GHz OS Vine Linux2.1 CPU PentiumⅡ   300MHz OS Vine Linux2.1 Packet loss generated 1,2,4,6,8,10% We compared the experimental values and the theoretical values Experimental values Measure after decoding RS codes
    20. 20. Result (15 , 13) (15 , 12) (15 , 11) The theoretical values and the experimental values are almost the same. Packet loss rate can be decreased from 11% to less than 1 % by using FEC.
    21. 21. Result (15 , 13) (15 , 12) (15 , 11) Packet loss 11 % non-FEC Using RS-FEC(15,11) 10 12 ~ ~ ~ ~
    22. 22. Distance Seminar using Broadcast mode Hiroshima City Univ. Hiroshima Univ. Saga Univ. Experimental IP Network (ATM 45Mbps) Jitter : 4ms Avg. packet loss :      0.000058 % RTT : 14.8ms Hiroshima City Univ. – Saga Univ. Jitter : 6ms Avg. packet loss : 0.120% RTT : 8.5ms Hiroshima-city Univ. -- Hiroshima Univ. Audio :  MRAT(160Kbps) Movie :  Mpeg2ts(5Mbps) Requirement bandwidth
    23. 23. Error recovery of packet losses using Broadcast mode The results of error recovery for only 100 seconds as a typical part during the seminar Packet losses are almost recovered by using broadcast mode
    24. 24. Distance Chorus Hiroshima City Univ. Hakushima Elementary School ( Main melody ) Minami-Kanon Elementary ( Sub melody ) Experimental IP network 10Mbps, wide area Ethernet 70 ~ 75ms Accompaniment Accompaniment Accompaniment Sub melody Main+Sub melody Accompaniment +Sub melody Accompaniment +Main melody Main melody 7 ms Jitter 2.1 ms Transfer delay 512 kbps Requirement bandwidth
    25. 25. Conclusion <ul><li>Classification of audio communication scenes </li></ul><ul><li>Development of a multipurpose audio transmission system, MRAT, and its evaluation </li></ul><ul><li>Some practical experiments such as a distance chorus at multi-points and distance seminars </li></ul><ul><li>Our system can be used in multiple audio communication scenes. </li></ul>
    26. 26. Future Problems <ul><li>New applications using each mode </li></ul><ul><li>Dynamic and adaptive changing of three modes depending on the requirements </li></ul>
    27. 27. Scalability of Distance Chorus <ul><li>How wide area to realize distance chorus? </li></ul><ul><li>Light propagation: 21000km in 70ms </li></ul><ul><li>We think practical chorus is in Metropolitan network within an area of a few hundreds kilometers. </li></ul>Considering this restriction, distance chorus is not realized in the worldwide on the Internet The most ideal situation It’s realizable as a regional network
    28. 28. Bandwidth of MRAT 66 ○ 52.8 GSM 160 × 128 VDVI 160 ○ 128 DVI 80 ○ 64 G726-40 120 ○ 96 G726-40 160 ○ 128 G726-40 200 ○ 160 G726-40 320 ○ 256 A-law 320 ○ 256 μ-law 640 ○ 512 Linear-16 Bandwidth of After RS encode [kbps] RS encode Bandwidth [kpbs] Encoding
    29. 29. The quality of sound comparison of MRAT and RAT This is the result that the noise of MRAT and RAT was measured. FFT was used for the measurement. 36.4 RAT 3.4 MRAT(Broadcast mode) The detected number of noise
    30. 30. To realize the Distance Chorus accompaniment Main melody Sub melody Ideal tolerant delay 70ms
    31. 31. Study of burst errors <ul><li>We use Reed-Solomon (15,11) code </li></ul>It could be almost recovered at distance seminar. We think this is adequate value. block numbers of recovery blocks All block numbers =  99.9584 % ― During distance seminar (15 packets in 1 block)
    32. 32. End-to-end delay bounds 150ms Delay not Perceived In most cases 400ms “ Natural” Interaction ITU-T G.114 ITU-T G.114 150ms 400ms Best medium
    33. 33. Where can you download? <ul><li>You can get MRAT here </li></ul><ul><li>http://www.mame.csi2.net/mrat/frame.html </li></ul><ul><li>sorry this page is Japanese only… </li></ul><ul><li>I’ll make English page from now. </li></ul><ul><li>Wait a minute. </li></ul>

    ×