Azure Monitor & Application Insight to monitor Infrastructure & Application
Development of a Multipurpose Audio Transmission System on the Internet
1. Development of a Multipurpose Audio Transmission System on the Internet Takashi Kishida Graduate School of Information Sciences, Hiroshima City University, Japan
2.
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.
5.
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. Audio Communication Scenes Distance Chorus Distance Lecture Audio conference Conversation 100ms 400ms End-to-end delay Low High 0ms Robustness
8.
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.
11. Read length variation This elapsed time related to delays. The longer elapsed time is, the longer delays are.
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.
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.
16.
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. 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. 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. 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. Result (15 , 13) (15 , 12) (15 , 11) Packet loss 11 % non-FEC Using RS-FEC(15,11) 10 12 ~ ~ ~ ~
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. 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. 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
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. To realize the Distance Chorus accompaniment Main melody Sub melody Ideal tolerant delay 70ms
31.
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.
Notas do Editor
I would like to present our paper entitled "Development of a Multipurpose Audio Transmission System on the Internet".