Abstract

This paper describes an Android mobile application thatallows voice communications through short-range wirelessnetworks, mainly Bluetooth and Wi-Fi. The application isable to replicate as close as possible the behavior of a two-way radio device. The application is designed to receiveaudio streams from multiple devices simultaneously andto send them. The main design considerations of the ap-plication, such as audio recording and playing, audio cod-ing or data transmission, are explained through the paper.

Keywords: Wireless networks, Android, data transmis-sion, audio coding.

1. Introduction

Application distribution platforms for mobile devices, suchas the App Store or the Android Market, have promotedthe appearance of an ever-increasing number of applica-tions, drastically changing the landscape of the market. Al-though Apple pioneered this change, the convenience ofthe Android platform for both device manufacturers andapplication developers has established the Android Marketas one of the most relevant application distribution plat-forms. Due to the fast growing number of Android termi-nals worldwide, application developers target this platformseeking for a massive number of potential users.

There are many different categories of applications suchas games, infotainment or access to social networks.Users can even find applications that supersede the na-tive communication applications of the phone, such asmessaging, audio or video communications. The success

of this kind of applications highlights the fact that al-though phones allow users to text or call each other,there are many use cases for which the native communi-cation applications just do not fit.

Regarding voice communications, there are different usecases traditionally addressed by other kinds of devices dif-ferent from mobile phones. Two-way radio transceiversallow peers to establish a voice communication withoutneeding additional infrastructure, provided that the de-vices are in range. This is very convenient in different sce-narios, especially where there is no coverage of cellularnetworks or just when users cannot afford maintainingan ongoing call alive for unlimited periods of time. Smart-phones have great connectivity thanks to technologiessuch as Wi-Fi or Bluetooth, but they are not providedwith voice applications allowing users to use them astwo-way radios with these technologies. This is the ob-jective of the application hereby presented, Android In-tercom: turn Android terminals into two-way radios usingtheir connectivity capabilities in the best way possible.

The rest of the paper is structured as follows: the nextsection explains the main design considerations of thedeveloped application, putting special emphasis on thedifferent wireless networks. Section 3 explains the maincharacteristics of the Android Intercom application. Fi-nally, some conclusions are presented.

2. Design considerations

This section describes the different design considerationstaken into account during the development of the appli-cation. Specifically, the next subsection shows the general

35Waves - 2012 - year 4/ISSN 1889-8297

Android real-time audio communications over localwirelessRomán Belda, Pau Arce, Ismael de Fez, Francisco Fraile and Juan Carlos Guerri

Instituto de Telecomunicaciones y Aplicaciones Multimedia, Universitat Politècnica de València, 8G Building - access D - Camino de Vera s/n - 46022 Valencia (Spain) Corresponding author: robelor@iteam.upv.es

architecture of the system, in which the main blocks ofthe application are presented: audio recording and play-ing, audio coding and data transfer. These blocks are ex-plained in the following subsections.

2.1 ArchitectureFig. 1 shows a general architecture of an audio transmissionapplication. It shows a typical chain of an audio flow. Firstly,audio is digitalized and recorded. Later, the recorded dataare usually packetized in samples of 20 or 30 ms. Thesesamples are encoded to minimize the transmission bit rateand finally are transmitted. In the developed application,data transmission is made through wireless networks,mainly Bluetooth and Wi-Fi. When the audio samples arriveat the listener device, the samples pass by an audio de-coder, which decode the data and send them to an audioplayer module where the audio is reproduced.

The application hereby presented is bidirectional, that is,the different devices work as transmitters and as re-ceivers. The figure shows a typical transmission from onedevice to another.

Moreover, Fig. 1 also reflects the main points to take intoaccount in the development of the application. Firstly, theaudio recording and playing blocks allow to capture andplayback audio, respectively. Audio needs to be encodedand then decoded through the corresponding blocks andfinally, the audio must be transmitted over a channel. Anextended analysis of each block is given below.

2.2 Audio recording and playing In the development of the audio recording and playingblocks, it must be taken into account that in Android themajor part of applications run on a dedicated instance ofthe Dalvik Java Virtual Machine (JVM). This characteristicmakes applications very sensitive to Garbage Collectorpauses, and that is why all Android multimedia Applica-tion Programming Interface (API) actually relies on nativecode [1].

Regarding audio, there are two Java-level APIs available:

• A high level API represented by MediaPlayer andMediaRecorder classes. This API has been built for en-coding [2], decoding and accessing media content.However, this API does not provide methods to accessstreams in a real-time manner, which makes it unfea-sible to develop applications that require real-timeaudio processing.

• A low level API represented by AudioTrack and Au-dioRecord classes. These classes are Java wrappers ofthe “libmedia” built-in native API.

Furthermore, two additional multimedia APIs have beenadded on newer Android versions. They are native APIsand are based on popular cross-platform multimedia sys-tems. The APIs are:

• OpenSL ES™ 1.0.1. Starting from Android API-level 9.• OpenMAX AL™ 1.0.1. Starting from Android API-level 14.

These native APIs are targeted to applications that mostlyrun native code. Before these libraries appeared, appli-cations like games, which usually run native code suchas Open GL, had to control audio from Java code instead,which resulted in unnecessary overhead.

All mentioned audio APIs work over the sound driver sys-tem. But there is no direct access to the sound system. Infact, there was no a standardized sound system. Only thelatest Android version (Ice Cream Sandwich) has estab-lished ALSA (Advanced Linux Sound Architecture) as thedefault sound system.

The lack of a good audio system from the beginning hascaused the fragmentation of sound implementations,most of them with very poor performance regardingsound latency matters [3]. As Android developers explainat last Google I/O [4], most of the latency is introducedby drivers and chipsets. Therefore, the solution to theproblem is likely to come in the form of a porting guidefor manufacturers, rather than a software patch.

The application presented in this paper uses the Java low-level audio API, since native APIs do not noticeably im-prove the latency. At this point, the API allows to recordand playback unencoded audio waveforms representedin pulse-code modulation (PCM) format. For the applica-tion under study, the characteristics of the recorded audioare: 8 kHz sampling frequency, 16 bits per sample and asingle channel.

Furthermore, as the objective of the application is tocover as much as possible use cases, three methods foractivating audio recording and sending have been devel-oped: static, manual and automatic. The first one consistsof an audio amplitude threshold that sends any soundthat is higher than the selected threshold. This thresholdis selectable by the user at any time by dragging themarker. The second one is a push to talk (PTT) mechanismthat uses volume or headset buttons to activate audiorecording and sending. The last input method analyzesaudio samples, background noise and instantaneous am-plitude in order to detect human voice. With any of thesethree methods, the application is able to reduce bothnoise and bandwidth usage. As the application could beused in a wide variety of use cases, the suitability of eachmethod will depend on the specific situation.

36 ISSN 1889-8297/Waves - 2012 - year 4

Figure 1. System architecture.

Smartphones have great connectivity but they lack ofdirect real time voice communication.

2.3 Audio CodingThe main goal of coding a media stream is to reduce theamount of transmitted data making the most of the intrin-sic characteristics of the media (e.g. correlation betweencontiguous samples). On the other hand, wireless technolo-gies used for local communications offer bandwidth ratesthat are more than enough to transmit several uncom-pressed audio streams. In this scenario, the question ofpower consumption arises: there is a trade-off betweendata compression, which reduces dramatically the band-width needed, and the processing consumption of the en-coding and decoding processes.

Moreover, another matter to take into account is the useof wireless communications and coverage ranges. Blue-tooth and Wi-Fi dynamically change their transmissionrate based on the signal to noise ratio. This entails thatthe transmission rate is the lowest at the border of thecoverage area.

There are many codecs successfully compiled for andused on the Android platform. Due to the Java and JVMscharacteristics, it is much more efficient to use C or C++codec versions through JNI (Java Native Interface) code.In this project, we use Speex [5], a widely-used opensource audio codec for voice applications. Speex can gen-erate constant or variable bit rates but the variable moderequires the use of floating point arithmetic, which is notusually present on mobile device processors.

Table 1 shows the available Speex encoder modes. A de-scription of the resulting audio quality, as well as thecomputational costs, is given for each mode.

We are using audio coding for this application due to theperspective of a better performance on coverage bordersand the low latency added by the coding and decodingprocess on mid-range device, usually less than 5 ms.When using the Speex codec we have to choose a modethat entails the quality level. As shown in Table 1, Speexmode 5 gives a good audio quality, compression rate andalgorithm complexity.

2.4 Data transferAs mentioned above, the application uses Bluetooth andWi-Fi as wireless networks to carry out data transmis-sions. Each one of these networks has its own character-istics and implementation details, which are discussed inlatter sections. In both cases it is necessary to define aprotocol to transport the encoded audio and control themanagement messages. For this task we use ProtocolBuffer [6]. This is a compiler that generates Java or C++code from a protocol definition language. An example ofhow an audio packet is defined in Protocol Buffer lan-guage is shown below.

message AudioMessage {message AudioSample {

required int32 seq_number = 1;required bytes audio = 2;

}required int32 user_id = 1;repeated AudioSample audio_sample = 2;

}

This code is used to serialize and parse to and from binarystreams. It defines a packet with a 32-bit identification(user_id) and an undefined number of audio samples(audio_sample), which in turn is composed by a sequencenumber (seq_number) and the audio bytes (audio).

Using Protocol Buffer as shown allows us to define acomplete protocol seamlessly, optimized and extensible.

2.4.1 BluetoothImplementing a two-way radio application over Blue-tooth [7] for Android devices presents many challenges.Firstly, Android devices need to be discoverable in orderto pair devices and for that it is required that the userowning the device to discover sets it in discoverablemode. This is necessary for Android versions previous to4.0, where there is an option to set the device into al-ways-discoverable mode. From now on, we will supposethat all devices that want to communicate over Bluetoothare already discovered and paired. If the target device isnot paired it is possible to access the system Bluetooth

37Waves - 2012 - year 4/ISSN 1889-8297

Table 1. Speex modes characteristics.

0 - 250 0 No transmission (DTX)

1 0 2 150 6 Vocoder (mostly for comfort noise)

2 2 5 950 9 Very noticeable artifacts/noise, good intelligibility

3 3-4 8 000 10 Artifacts/noise sometimes noticeable

4 5-6 11 000 14 Artifacts usually noticeable only with headphones

5 7-8 15 000 11 Need good headphones to tell the difference

6 9 18 200 17.5 Hard to tell the difference even with good headphones

7 10 24 600 14.5 Completely transparent for voice, good quality music

8 1 3 950 10.5 Very noticeable artifacts/noise, good intelligibility

Mode Quality Bit rate (bps) mflops Quality/description

settings from the settings section of the application topair them. These needs to be taken into account in thedesign of the user interface, so that the process of estab-lishing a connection is as simple as possible.

Pairing is necessary for establishing secure connections.Secure connections were the unique possibility on An-droid versions 2.3.3. Since that version it is possible toestablish unsecured connections to unpaired devices butthose devices still need to be discoverable and the featureof being always discoverable, as commented before, it isonly present starting at Android 4.0. To keep compatibil-ity with the mayor number of devices only secured con-nections are used by the application.

Once the devices are paired, the only Bluetooth profilethat is available in the public API is the Bluetooth SerialPort Profile (SPP). The Bluetooth SPP provides a RFCOMMconnection. A RFCOMM connection provides a reliabletransmission, error detection and flow control, which arenot well fitted for time dependent data. Note that itwould have been preferable to be able to access to Ad-vanced Audio Distribution Profile (A2DP). AD2P is basedon Generic Audio/Video Distribution Profile (GAVDP) andallows the distribution of high quality real-time audiostreams.

To reach a good performance on real-time voice commu-nications, a queue system on transmission and receptionhas been developed to avoid RFCOMM real-time draw-backs as much as possible.

Fig. 2 shows the four kinds of queue used. BluetoothOutput Queue (BOQ) and Bluetooth Input Queue (BIQ)are system queues that cannot be controlled at applica-tion layer. These queues are designed to avoid undesir-able effects of the RFCOMM protocol.

Regarding the other two queues, in a favorable transmis-sion scenario, Bluetooth links offer much more bandwidththan needed. In this scenario, Application Output Queue(AOQ) and Application Input Queue (AIQ) are only actingas an audio record and playing jitter reduction/avoidancebuffers.

When Bluetooth links become weak BIQ empties andBOQ fills because the audio encoder bit rate is higherthan the connection capacity. In this scenario, samplesadded to the BOQ cannot be removed and will be trans-mitted if the Bluetooth stack does not fire a time out ex-ception. Consequently, the AOQ will be filled and willdrop samples in a First In First Dropped (FIFD) manner. Aspointed out above, encoding audio will help to avoid getinto this situation because of the considerably narrowerbandwidth needed by it.

When the Bluetooth links become strong again storedsamples from the BOQ and from the AOQ will arrive tothe receiver in a burst because, as we have already said,Bluetooth links offer much more bandwidth than the re-quired by a coded audio stream. On the receiver side, theBluetooth reader thread will try to keep the BIQ as emptyas possible and will drop any sample that has arrived outof time. Typically, the samples are stored at BOQ.

After a sample burst all the queues but the AIQ are in itsinitial state. To adjust the size of AIQ the pitch of the sam-ple consumer player can be modified in order to let it actas a jitter buffer.

2.4.2Wi-FiReal-time communications are very sensitive to packetdelay and jitter. Usually, when losses occur, it is better toignore lost audio frames, or even drop stale packets, thanjust wait for retransmissions. In this sense, transport pro-tocols that are not connection-oriented are more suitablefor this kind of transmissions. Within the TCP/IP protocolstack, UDP is able to encapsulate audio packets withoutproviding any retransmission mechanism, which wouldcause interruptions and undesired effects in a real-timecommunication. Nevertheless, it is worth noting thatMAC layer in Wi-Fi communications, which uses 802.11standard, has its own mechanism for acknowledgingpackets at lower level, so additional considerations haveto be taken into account, as explained below.

Moreover, commercial devices do not present a homoge-neous behavior regarding the way they manage UDP pack-ets. Most of them block incoming broadcast traffic, andthose who admit broadcast packets cannot receive themin standby mode. This is due to the energy-saving mecha-nism of the modern smartphones, which switch the wire-less card almost off while the device is locked and thescreen is off. Android version 3 and above provides thefunctionality to maintain the wireless card fully operativeeven though the screen is off. Anyway, experimental testshave shown that this issue occurs only when receiving andthere is no difficulty when sending broadcast packets.

38 ISSN 1889-8297/Waves - 2012 - year 4

Android Intercom allows placing real-time calls overBluetooth and Wi-Fi.

Figure 2. Bluetooth communication queues.

Broadcast messages are commonly used for discoveringpeers in the same network and for broadcasting generalinformation about the nodes. Sometimes, broadcast traf-fic (or multicast) is used in point-to-multipoint commu-nications (from one to several). In order to solve theaforementioned problems of broadcast packets attachedto the heterogeneity of commercial smartphones, wehave designed a hybrid unicast-broadcast communicationmechanism, which detects at first if the device supportsbroadcasting.

Mainly, the developed system consists of two phases:peer discovering and audio communication. The neigh-bor discovering process uses broadcast packets unless thedevice does not manage to find any node in the network.In that case, unicast scanning starts to find new peers.Every user must be able to listen to other users in the net-work so audio communication should be carried outusing broadcast packets to profit the point-to-multipointnature of the system. However, another mechanism isneeded for those devices that cannot receive broadcasttraffic. Therefore, these devices inform of these limita-tions in the discovering process so other nodes can beaware. Broadcast audio communication will be used be-tween those nodes that support it whereas unicast audiocommunication will be used for those nodes that do not.Regarding packet acknowledgement in Wi-Fi networks,unicast and broadcast transmissions differ. The former isacknowledged through ACK packets at MAC layer, re-gardless of the transport protocol used. In contrast, thelatter cannot use acknowledgements due to the point-to-multipoint nature of broadcast transmissions. This factmotivates the use of a redundancy mechanism againstlosses for broadcast packets, but not for unicast trans-missions. In this sense, a Forward Error Correction (FEC)mechanism has been implemented, which adds parity in-formation to the transmitted data. Therefore, everybroadcast packet transports an audio frame and two par-ity frames that could be potentially used to correct anyprevious lost audio frame.

3. Android Intercom Application

3.1 Wireless scenariosThere are two scenarios for the application based on thewireless technology to use: the Bluetooth scenario andthe Wi-Fi scenario. Both of these approaches have theiradvantages and disadvantages.

On the Bluetooth scenario devices have to select theother devices to connect to. The need of selecting thedevices to connect faces up to the two-way radio con-cept but it is enforced by the Bluetooth needs of discov-ering and pairing. For performance reasons the totalnumber of devices interconnected on Bluetooth mode islimited to three. This limit has been obtained experimen-tally using the Google Nexus One as test device. On tests,four devices have never been able to talk simultaneouslywithout causing voice interruptions.

Once every device has selected the others the applicationshould handle all events of the Bluetooth connections toseamless control connection losses, discoveries and recon-nections. When a user wants to speak the others everysample should be sent to each device connected to.

On the other hand, the Wi-Fi scenario is more similar toa two-way radio channel where the BSSID replaces theradio channel. Also, broadcast Wi-Fi packets are moresuitable for one-to-many communications than manyone-to-one. The limit of the wifi scenario is farther thanour device limit. It has been tested with up to ten devicessimultaneously without problems.

There are two Wi-Fi scenarios depending of the workingmode. On the infrastructure mode every packet is trans-mitted through the access point (Fig. 4). On ad-hoc Wi-Fimode there is no access point and devices communicate

39Waves - 2012 - year 4/ISSN 1889-8297

Figure 3. Bluetooth scenario.

Figure 4. Infrastructure Wi-Fi scenario.

Android Intercom is being successfully used by thou-sands of users worldwide.

directly (Fig. 5). Despite its versatility, Android platform seg-regates the ad-hoc mode and only few commercialized de-vices support it. Mesh networking on ad-hoc Wi-Fi modehas been discarded because of its power consumption is-sues [8].

3.2 Android IntercomThe developed application has been published on GooglePlay (the most popular online store for Android applica-tions), with the name of “Android Intercom”, and hasreached more than 50.000 downloads since its publica-tion. The local scope of communications limits its usecases in number but greatly improve its value when thereis not Internet access. Motorcycle helmet-to-helmet com-munications, in-building communications and baby mon-

itoring are the top three use cases based on the numberof feedback comments received. Fig. 6 shows threescreenshots from the application. In Bluetooth mode (Fig.6a) users have two channels available to create point-to-point connections to other users. Wi-Fi mode let usersfind other devices in the same network and talk to themall together (Fig. 6b). Both modes show the audio record-ing level and threshold, depending on the algorithm ofvoice detection employed. Moreover, through the micro-phone preferences screen (Fig. 6c), users can adjust thesensitivity of the microphones connected to the device(e.g. built-in, mini-jack, Bluetooth), since each kind of mi-crophone has its own variability.

The application can be downloaded free of charge atGoogle Play store. The QR code on the Fig. 7 containsthe url of the download page.

40 ISSN 1889-8297/Waves - 2012 - year 4

Figure 5. Ad-hoc Wi-Fi scenario.

Figure 7. QR code to access the download page atGoogle Play store

Figure 6. Android Intercom application: Bluetooth mode screen (a), Wi-Fi mode screen (b) and microphone preferencesscreen (c).

(a) (b) (c)

4. Conclusions

In this paper we have presented the key points of the de-velopment of an Android application for real-time audiocommunication over local-range wireless technologies.Furthermore, we have discussed about design consider-ations and technical problems that emerge when imple-menting algorithms and communication protocols inreal-world devices. Thus, we have developed workaroundsolutions for efficient voice transmission over Bluetoothand Wi-Fi with the tools that Android public APIs offer.The developed application is being successfully used bythousands of users worldwide and for many different usecases. Following improvements will include Wi-Fi Directas emerging wireless communication technology. Asmentioned, Android has avoided using p2p networkingthrough ad hoc wireless networks. Instead, it has pro-moted using the new Wi-Fi Direct specification, whichenables p2p relationships. On each relation, one of thepeers is acting as access point and the other as a normalclient. This new approach to p2p wireless networking isvery promising for our application, which will improve us-ability and simplicity.

References

[1] M. Song, W. Xiong and X. Fu, “Research on Architec-ture of Multimedia and Its Design Based on Android,”in Proc. of Int. Conf. on Internet Technology and Ap-plications, Wuhan, China, Aug. 2010.

[2] Android Codecs, available: http://developer.android.com/guide/appendix/media-formats.html

[3] Android issue 3434, available: http://code.google.com/p/android/issues/detail?id=3434.

[4] Google I/O 2011: Fireside Chat with the AndroidTeam, available: http://youtu.be/gfiYUL2exT8.

[5] P. Srivastava, K. Babu and T. OSV, “Performance Evalua-tion of Speex Audio Codec for Wireless CommunicationNetworks,” in Proc. Wireless and Optical Commu -nications Networks 2011, Ghaziabad, India, 2011.

[6] G. Kaur and M.M. Fuad, “An Evaluation of ProtocolBuffer,” in Proc. of IEEE SoutheastCon 2010, pp. 459-462, Charlotte-Concord, NC, USA, Mar. 2010.

[7] M.J. Morón, R. Luque, E.Casilari and A. Díaz-Estrella,“Minimum delay bound in Bluetooth transmissionswith serial port profile,” IET Electronic Letters, pp.1099-1100, Vol.44, no.18, 2008.

[8] A. Iera, A. Molinaro, S. Y. Paratore, G. Ruggeri and A.Zurzolo, “Making a mesh router/gateway from asmartphone: Is that a practical solution?,” Ad HocNetworks, pp. 1414-1429, Vol.9, 2011.

Biographies

Román Belda was born in Alzira(Valencia), Spain. He received theComputer Science degree from theUniversidat Politècnica de València(UPV), Valencia, Spain, in 2004. Heis currently working towards theM.S. in telematics at UPV. He alsocurrently works as a Researcher atthe Multimedia Communications

research group (COMM) of the Institute of Telecommu-nications and Multimedia Applications (iTEAM). His areasof interest are mobile applications and multimedia trans-mission protocols.

Pau Arce was born in Valencia,Spain. He received the Telecommu-nications Engineering degree andthe M.S. degree in Telematics fromthe Universitat Politècnica de Valèn-cia (UPV), Valencia, Spain, in 2005and 2007, respectively. Currently,he works as a researcher at the In-stitute of Telecommunications and

Multimedia Applications (iTEAM) UPV, where he is work-ing toward the Ph. D. degree. His research interests in-clude multimedia QoS, routing on wireless ad hocnetworks and performance evaluation of computer sys-tems.

Ismael de Fez was born in Valen-cia, Spain. He received the Telecom-munications Engineering degreeand the M.S. degree in Telematicsfrom the Universitat Politècnica deValència (UPV), Valencia, Spain, in2007 and 2010, respectively. Cur-rently, he is a Researcher at theMultimedia Communications re-

search group (COMM) of the Institute of Telecommuni-cations and Multimedia Applications (iTEAM), UPV, wherehe is working toward the Ph. D. degree. His areas of in-terest are file transmission over unidirectional environ-ments and file encoding.

41Waves - 2012 - year 4/ISSN 1889-8297

Francisco Fraile was born in Mur-cia, Spain. He obtained a degree inTelecommunication Engineeringfrom the Universitat Politècnica deValència (UPV) and the M. Sc. De-gree in microwave engineeringfrom the University of Gävle in2004. Since then, until 2010, hehas worked as a Research Engineer

for the Swedish company Interactive TV Arena. In 2006,he joined the Multimedia Communications researchgroup (COMM) of the iTEAM Institute, UPV, where he isworking toward his doctoral studies as an industrial Ph.D.student. His area of interest focuses on networked elec-tronic media.

Juan Carlos Guerri was born inValencia. He received his M.S. andPh. D. (Dr. Ing.) degrees, both intelecommunication engineering,from the Universitat Politècnica deValència (UPV), in 1993 and 1997,respectively. He is a professor in theE.T.S. Telecommunications Engi-neering at the Universitat Politèc-

nica de València, where he leads the MultimediaCommunications research group (COMM) of the iTEAMInstitute. He is currently involved in research and devel-opment projects for the application of multimedia to in-dustry, medicine, education, and communications.

42 ISSN 1889-8297/Waves - 2012 - year 4