Skip to content

Most visited

Recently visited

navigation
Added in API level 12

AudioGroup

public class AudioGroup
extends Object

java.lang.Object
   ↳ android.net.rtp.AudioGroup


An AudioGroup is an audio hub for the speaker, the microphone, and AudioStreams. Each of these components can be logically turned on or off by calling setMode(int) or setMode(int). The AudioGroup will go through these components and process them one by one within its execution loop. The loop consists of four steps. First, for each AudioStream not in MODE_SEND_ONLY, decodes its incoming packets and stores in its buffer. Then, if the microphone is enabled, processes the recorded audio and stores in its buffer. Third, if the speaker is enabled, mixes all AudioStream buffers and plays back. Finally, for each AudioStream not in MODE_RECEIVE_ONLY, mixes all other buffers and sends back the encoded packets. An AudioGroup does nothing if there is no AudioStream in it.

Few things must be noticed before using these classes. The performance is highly related to the system load and the network bandwidth. Usually a simpler AudioCodec costs fewer CPU cycles but requires more network bandwidth, and vise versa. Using two AudioStreams at the same time doubles not only the load but also the bandwidth. The condition varies from one device to another, and developers should choose the right combination in order to get the best result.

It is sometimes useful to keep multiple AudioGroups at the same time. For example, a Voice over IP (VoIP) application might want to put a conference call on hold in order to make a new call but still allow people in the conference call talking to each other. This can be done easily using two AudioGroups, but there are some limitations. Since the speaker and the microphone are globally shared resources, only one AudioGroup at a time is allowed to run in a mode other than MODE_ON_HOLD. The others will be unable to acquire these resources and fail silently.

Using this class requires RECORD_AUDIO permission. Developers should set the audio mode to MODE_IN_COMMUNICATION using setMode(int) and change it back when none of the AudioGroups is in use.

See also:

Summary

Constants

int MODE_ECHO_SUPPRESSION

This mode is similar to MODE_NORMAL except the echo suppression is enabled.

int MODE_MUTED

This mode is similar to MODE_NORMAL except the microphone is disabled.

int MODE_NORMAL

This mode indicates that the speaker, the microphone, and all AudioStreams in the group are enabled.

int MODE_ON_HOLD

This mode is similar to MODE_NORMAL except the speaker and the microphone are both disabled.

Public constructors

AudioGroup()

Creates an empty AudioGroup.

Public methods

void clear()

Removes every AudioStream in this group.

int getMode()

Returns the current mode.

AudioStream[] getStreams()

Returns the AudioStreams in this group.

void sendDtmf(int event)

Sends a DTMF digit to every AudioStream in this group.

void setMode(int mode)

Changes the current mode.

Protected methods

void finalize()

Invoked when the garbage collector has detected that this instance is no longer reachable.

Inherited methods

From class java.lang.Object

Constants

MODE_ECHO_SUPPRESSION

Added in API level 12
int MODE_ECHO_SUPPRESSION

This mode is similar to MODE_NORMAL except the echo suppression is enabled. It should be only used when the speaker phone is on.

Constant Value: 3 (0x00000003)

MODE_MUTED

Added in API level 12
int MODE_MUTED

This mode is similar to MODE_NORMAL except the microphone is disabled.

Constant Value: 1 (0x00000001)

MODE_NORMAL

Added in API level 12
int MODE_NORMAL

This mode indicates that the speaker, the microphone, and all AudioStreams in the group are enabled. First, the packets received from the streams are decoded and mixed with the audio recorded from the microphone. Then, the results are played back to the speaker, encoded and sent back to each stream.

Constant Value: 2 (0x00000002)

MODE_ON_HOLD

Added in API level 12
int MODE_ON_HOLD

This mode is similar to MODE_NORMAL except the speaker and the microphone are both disabled.

Constant Value: 0 (0x00000000)

Public constructors

AudioGroup

Added in API level 12
AudioGroup ()

Creates an empty AudioGroup.

Public methods

clear

Added in API level 12
void clear ()

Removes every AudioStream in this group.

getMode

Added in API level 12
int getMode ()

Returns the current mode.

Returns
int

getStreams

Added in API level 12
AudioStream[] getStreams ()

Returns the AudioStreams in this group.

Returns
AudioStream[]

sendDtmf

Added in API level 12
void sendDtmf (int event)

Sends a DTMF digit to every AudioStream in this group. Currently only event 0 to 15 are supported.

Parameters
event int
Throws
IllegalArgumentException if the event is invalid.

setMode

Added in API level 12
void setMode (int mode)

Changes the current mode. It must be one of MODE_ON_HOLD, MODE_MUTED, MODE_NORMAL, and MODE_ECHO_SUPPRESSION.

Parameters
mode int: The mode to change to.
Throws
IllegalArgumentException if the mode is invalid.

Protected methods

finalize

Added in API level 12
void finalize ()

Invoked when the garbage collector has detected that this instance is no longer reachable. The default implementation does nothing, but this method can be overridden to free resources.

Note that objects that override finalize are significantly more expensive than objects that don't. Finalizers may be run a long time after the object is no longer reachable, depending on memory pressure, so it's a bad idea to rely on them for cleanup. Note also that finalizers are run on a single VM-wide finalizer thread, so doing blocking work in a finalizer is a bad idea. A finalizer is usually only necessary for a class that has a native peer and needs to call a native method to destroy that peer. Even then, it's better to provide an explicit close method (and implement Closeable), and insist that callers manually dispose of instances. This works well for something like files, but less well for something like a BigInteger where typical calling code would have to deal with lots of temporaries. Unfortunately, code that creates lots of temporaries is the worst kind of code from the point of view of the single finalizer thread.

If you must use finalizers, consider at least providing your own ReferenceQueue and having your own thread process that queue.

Unlike constructors, finalizers are not automatically chained. You are responsible for calling super.finalize() yourself.

Uncaught exceptions thrown by finalizers are ignored and do not terminate the finalizer thread. See Effective Java Item 7, "Avoid finalizers" for more.

Throws
Throwable
This site uses cookies to store your preferences for site-specific language and display options.

Hooray!

This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.