IT. Expert System.

Android Reference


Class AudioGroup

  • public class AudioGroup
    extends Object
    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 RtpStream.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 RtpStream.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 RtpStream.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 android.Manifest.permission#RECORD_AUDIO permission. Developers should set the audio mode to AudioManager.MODE_IN_COMMUNICATION using AudioManager.setMode(int) and change it back when none of the AudioGroups is in use.

    See Also:
    • Field Detail

      • MODE_ON_HOLD

        public static final int MODE_ON_HOLD
        This mode is similar to MODE_NORMAL except the speaker and the microphone are both disabled.
        See Also:
        Constant Field Values

        public static final 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.
        See Also:
        Constant Field Values

        public static final 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.
        See Also:
        Constant Field Values
    • Constructor Detail

      • AudioGroup

        public AudioGroup()
        Creates an empty AudioGroup.
    • Method Detail

      • getMode

        public int getMode()
        Returns the current mode.
      • sendDtmf

        public void sendDtmf(int event)
        Sends a DTMF digit to every AudioStream in this group. Currently only event 0 to 15 are supported.
        IllegalArgumentException - if the event is invalid.
      • clear

        public void clear()
        Removes every AudioStream in this group.
      • finalize

        protected void finalize()
                         throws Throwable
        Description copied from class: Object
        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.

        finalize in class Object


Android Reference

Java basics

Java Enterprise Edition (EE)

Java Standard Edition (SE)





Java Script








Design patterns

RFC (standard status)

RFC (proposed standard status)

RFC (draft standard status)

RFC (informational status)

RFC (experimental status)

RFC (best current practice status)

RFC (historic status)

RFC (unknown status)

IT dictionary

All information of this service is derived from the free sources and is provided solely in the form of quotations. This service provides information and interfaces solely for the familiarization (not ownership) and under the "as is" condition.
Copyright 2016 © ELTASK.COM. All rights reserved.
Site is optimized for mobile devices.
Downloads: 248 / 158851157. Delta: 0.03354 с