Walkie talkie android studio project report pdf download

This means that when one device is sending audio data, the other device is receiving not transmitting and vice-versa. Skip to content. Star A bluetooth based push to talk app for Android. Branches Tags. Could not load branches. Could not load tags. Latest commit. These instructions will get you a copy of the project up and running on your local machine for development and testing purposes.

See deployment for notes on how to deploy the project on a live system. Whether partial or complete, the failure of communications infrastructure leads to preventable loss of life and damage to property, by causing delays and errors in emergency response and disaster relief efforts. One solution to this problem is to use our app for communication.

As this app doesn't need any infrastructure for communication, people can use this as a means for communication. Communication on Motercycle Some cool ways people can use our technology to enhance riding, making it better, safer, and more fun! Have live conversations with other riders in your group, so you can make route changes, signal any problems, or just make conversation while cruising.

Talk to your passenger while riding, and even stream your own music to their speakers so you can both enjoy the same playlist. Train other riders by following along behind them, giving them real-time coaching tips through the intercom. There are existing devices which use Bluetooth as a medium to provide the above features. While such system works but they have some disadvantage like coverage upto m Bluetooth coverage and slow transmission rate upto kbps.

Therefore, we create two steps registration mechanism to handle this issue. If the device is not a group owner, it must registers its' IP address to the group owner.

After that the group owner can help to disseminate members' address to other devices. For the Beacon Flow, the Beacon Broadcast Socket Client will keep broadcast the control message which including the IP address and the virtual frequency.

If the user updates the virtual frequency, this broadcast socket will help to send new beacon message to peers immediately. The Beacon Accept Socket Server helps to receive beacon messages, extract the frequency information and inform the received frequency to upper layer.

After the beacon exchanging, each device will receive the control message from each other. Therefore, the Frequency Manager will generate a table to maintain the frequency of peers. The second type of flow is Audio Flow which handles audio communication messages.

When the Walkie-Talkie is turned on, the Audio-Player Thread is created and is run in the background. Therefore, the user can hear the voice played by the Audio-Player Thread. If the user pushes the talk button, the Audio Recorder object will be created to record voice and send audio message to down layer. The down layer Audio Msg Socket will create sockets and send out the audio message to those devices in the same frequency group.

Even we are going to implement walkie-talkie feature thru wifi-direct in android devices. Our goal is to achieve to realize the real-time talking among peers.

This real time talk is very similar to a phone call. Even android does not explicitly explain how the audio recording and audio playing back work. The related audio queue architecture explanation can be found in [1]. We believe the Android audio architecture is very similar to the Mac one. Maybe this similarity is why Android does not mention what its audio queue architecture is.

As mentioned in [1] an audio queue has the following responsibilities:. Since audio queue is connected to audio hardware and mediating recording or playback. Therefore the effectiveness of audio queue depends on the hardware. Every audio queue has virtually the same common data structure, containing three key elements:.

As shown in Figure 8, the incoming audio is acquired by a microphone. And the incoming audio is stored and maintained by an audio queue.

Figure 9 shows how the process audio recording works. Audio Queue fills or feeds the incoming audio into Buffers in the Buffer Queue of the recorder. When a buffer if fully charged or filled, the callback is triggered, and this full buffer is polled or popped out of the Buffer queue to be read to our walkie-talkie application. At the same time another buffer is pushed to the head of the buffer queue of recorder to begin to be filled or charged.

Once the previous full buffer is read to the walkie-talkie and become empty, this empty buffer is returned to the Buffer Queue and pushed to the end of the audio buffer queue to be recharged or filled again. In our walkie-talkie, we use our own audio queue to store the full buffers read from the audio Buffer queue of recorder. The reason why we use our own audio queue to store the audio buffer instead of forwarding this buffer directly is the latency issue.

If the latency to forward a buffer to the destination was too high, the empty buffer would not be return to the buffer queue to be recharged in time. Then the quality of audio recording would be influenced.

In real time, the full buffer in our walkie-talkie queue is forwarded to the destination through our protocol on top of wifi-direct sockets. Buffer size depends on the sampling rate and different android devices.

In our walkie-talkie we used sampling rate with for the buffer recording. As shown in Figure 10, the outgoing audio is entering the loudspeaker. The incoming audio full buffers are being received from the sender by using protocol on top of wifi-direct. However, the callback mechanism is on the left side of Audio Queue different from the right side of Audio Queue in Audio Recording. Figure 11 shows how the process audio playback works. These incoming audio full buffers are stored in our own audio buffer queue in walkie-talkie.

The reason to employ our own full buffer queue is to eliminate the non synchronization of the incoming data and the outgoing data. The buffer in our own audio buffer queue is written into the buffer in the audio queue of the audio player. This writing process is controlled by a callback mechanism. When the buffer is empty in the Audio Queue, it triggers callback to read data from our walkie-talkie audio buffer queue. Once the buffer is fully filled or charged this full buffer is pushed into the buffer queue of the audio player to be lined up to be played.

As soon as the full buffer finishes its playing, this empty buffer is popped out and triggers another callback to write audio data from our walkie-talkie buffer queue. Simultaneously the full buffer in the second place is pushed to the head of the buffer queue to be playing. In our walkie-talkie we used sampling rate with for playback which is the same as the audio recording.