The technical realization behind the audio transmission

Now the popular TV box is mostly Android, "audio transmission" is a frequent word, that is what is audio transmission, audio through the technology behind the realization of the end, aroused my interest, so took a little time to study a bit. Due to the analysis of the TV box scheme for the whole Chi H8, the results of the analysis are not universal, and other schemes may differ in the technical implementation.

In the beginning of the analysis of the concept of "through the transmission" of the explanation, according to the degree Niang said that is "transparent transmission, that is, transmission network regardless of transmission business, only responsible for the transfer of the business to the destination node, while ensuring the quality of transmission, but not the transmission of business processing", Although and the audio is not border, but the basic meaning is "data without any modification from the sending side to the receiving end", can roughly determine the audio transmission is similar to the meaning.

Next look at some of the property definitions for audio output in Android, and some of the information collected and analyzed in the previous study of the audio subsystem (based on KitKat):

typedef enum {  Audio_output_flag_none = 0x0,  audio_output_flag_direct = 0x1,  audio_output_flag_primary = 0x2,  audio_output_flag_fast = 0x4,  audio_output_flag_deep_buffer = 0x8,  audio_output_flag_compress_ Offload = 0x10,  audio_output_flag_non_blocking = 0x20} audio_output_flags_t;

In these attributes, each has its own characteristics:

Direct: Do not perform software mixing directly to the HAL for processing;

PRIMARY: Software decoding, software mixing, sample rate conversion (SRC) What is not a few;

FAST: No sample rate conversion (SRC);

Deep_buffer: The original data is uncompressed PCM, processed directly by the HAL;

COMPRESS_OFFLOAD: Encoded data directly to the HAL for processing (often need to have a DSP hard decoding);

Non_blocking: Why don't you tell me;

The following shows the relationship between primary and fast (based on Jellybean,kitkat roughly the same):

The following shows the relationship between primary, FAST, and Deep_buffer (which should be based on KitKat):

From this figure, Deep_buffer is playing music in the off state, and need Hal's support, I have not encountered this way of working in the actual work, in this diagram, the direct method is not reflected, and the difference between the primary is the playback mode of different The former is through directoutputthread so software mixing is not possible, the latter is mixerthread so software can be mixed.

Having finished the rough analysis of the audio subsystem, we can now look at the block diagram of the H8 TV box scheme provided by the mother:

The HDMI controller input signal can be a combination of video signal or a separate video signal, the former output signal into the TV by the speaker of the TV, but due to the sound quality of the TV horn, you can choose the latter will audio signal through the amplifier by the speaker sound. In the H8 TV box scheme, audio PCM data (most likely via I2S) is transmitted to the AXP818 for DA conversion after the amplifier is audible by the speaker, so the use of the elimination method can be initially in direct, Deep_buffer, Compress_ Offload three ways to determine one, Compress_offload relies on the existence of DSP can be denied, direct and deep_buffer are possible, but based on two considerations I think direct is the most likely, first, Google's Audio_ In the policy.conf example, HDMI is the direct way to use; second, Deep_buffer is smaller, direct development and maintenance easier. Of course, the audio transmission is based on the direct way of the HDMI is because of the deep_buffer do not understand the circumstances to make personal conclusions.

The technical realization behind the audio transmission