Decoder for graphic coding of vehicle-mounted sadsp system

Abstract

According to the decoder for graphic coding of the vehicle-mounted sadsp system, an encoder of a PC end records all processing logics of multimedia audio effects and scene effects through text codes in a code format and a combined code format, the text codes are sent to the vehicle-mounted system, and the text codes are read based on the decoder. The decoder decodes the code in the text format based on the decoding module, the decoded code is generated into the executable code supported by the system through the sadsp processing stream generation module, the decoding processing logic in the decoding module is simple and clear, the calculation amount is small, the text code can be quickly and accurately converted into the executable code supported by the vehicle-mounted system, and the method is suitable for the vehicle-mounted system. The method is ensured to have universality and is suitable for various vehicle-mounted systems in different forms.

Description

Technical Field

[0001] The present application relates to the technical field of vehicle-mounted audio processing, and in particular to a decoder for graphics coding of a vehicle-mounted sadsp system. Background Art

[0002] In order to improve the user experience, the existing in-vehicle multimedia systems of smart vehicles will set different sound effects and scene effects for users to choose from. At present, these sound effects and scene effects are realized through hardware digital signal processing chips, such as: ADI, NXP, AK chips are commonly used audio processing chips. The audio processing process based on hardware chips is: technicians adjust various audio effects according to needs based on ADI's SigmaStudio graphical development environment on the PC side. Because the adjustment process is based on the audio digital signal processing chip dsp in the car audio system, the hardware chip parameters corresponding to each sound effect and scene are sent to the car system and executed on the chip. However, because the hardware parameters are adjusted directly for the dsp chip in the car system, if the car system changes the model or manufacturer of the dsp chip, even if the car system's demand for audio effects has not changed, various sound effects and scenes must be redeveloped, increasing the R&D cost.

[0003] In order to reduce the system development cost, our company implements the audio processing flow in the vehicle system in the form of pure software. Figure 1 and Figure 2 As shown, firstly, all debugging functions supported by all audio data graphics development tools in the prior art are implemented based on components in the form of software, and then all debugging functions supported by the audio data graphics development tools are recorded through the component library. On the PC side, the component library is built in the encoder, and the processing logic of all multimedia audio effects and scene effects is recorded based on the encoder through text codes in code format and combined code format, and the text code is sent to the vehicle system, and read based on the decoder in the vehicle system. The code describing the sound effects and scene adjustments is transmitted between the PC and the vehicle system based on text in txt format. Text is a universal code-recognizable format, which does not require third-party parsing and can be parsed through a simple formatted input interface.

[0004] In the PC-side encoder, coding rules are constructed for the operations of various components. Figure 3 As shown, the component code rules constructed for the component are: [input 1, input2, ... input N]component_name[switch, component parameter 1, …, component parameter M][ output]; Among them, N means that the component includes N component inputs in total, M means that the component includes M component parameters; component_name is the component name; input and output represent the input and output of the component.

[0005] For scenarios where multiple components process signals in sequence, such as Figure 4 As shown, the rules for constructing the combined code are: [input] compnent_name 1 [switch, component parameter set][ output component name 1][output component name 1] compnent_name2[switch, component parameter set][ output component name 2][output component name 2]...compnent_namen[switch, component parameter set][output component name n]; In the formula, the input of the next level is set to be the same as the output of the previous level, indicating that the two signal processing are connected together; n means that the combination includes n components; the component parameter set is: component parameter 1, …, component parameter M. And all the codes in the same combination are on the same line.

[0006] A decoder is built into the vehicle system. When the decoder receives the text code to be processed, it decodes the received text code and then generates executable code supported by the system. So, how to build a universal decoder is a problem that needs to be solved. Summary of the invention

[0007] In order to solve the problem that there is no decoder for text codes in the audio processing flow of the in-vehicle multimedia system in the prior art, the present application provides a decoder for graphics coding of an in-vehicle sadsp system, whose debugging process does not rely on a specific hardware chip, and can quickly and accurately decode the received text code and generate executable code supported by the in-vehicle system.

[0008] The technical solution of the present application is as follows: a decoder for graphics coding of an on-vehicle sadsp system, characterized in that it comprises: a decoding module and a sadsp processing stream generating module; After receiving the text code sent by the encoder, the decoder sends all legal text codes to the decoding module; The decoding module decomposes the text code according to each of the components to obtain execution data corresponding to each of the components; The sadsp processing flow generation module generates executable codes in a form supported by the vehicle-mounted system, constructs the sadsp processing flow based on the executable codes, and sends the sadsp processing flow to the signal processing module in the vehicle-mounted system for execution; A processing flow code is generated based on the text code, and the processing flow code is sent to a signal processing module in the vehicle system for execution.

[0009] It is further characterized by: It also includes: a validity detection module; The validity check contents performed based on the validity detection module include: The received text code is formatted and checked for validity according to the component code rules and the combination code rules; the corresponding parameters and the legal rules of the parameters are confirmed according to the component names, and the legality of each parameter is checked; the component names corresponding to all components included in the text code must be in the preset component name definition set; The decoder also includes a component description file; The component description file contains the component information of all legal components: The component information includes: component name, parameter list and legal range of each parameter; When the decoder receives the text code to be processed, it analyzes and decodes it according to the following steps: a1: Traverse all the text codes to be processed and find all component names; a2: According to the component code structure, find the input, parameter and output corresponding to each component name, and record them together with the component name as: component code to be processed; a3: storing all component codes to be processed into a cache array according to their sequence in the text code to be processed; a4: confirm the input included in each component code to be processed; Find all the component codes to be processed that do not include other component names in the input, and record them as: initial input component; Assume that there are N initial input components in total; If N=1, it means that the text code to be processed includes only one complete path. The text code to be processed is recorded as: code combination to be converted, and all components included in it are recorded as: components to be converted; execute step a5; Otherwise, execute the code segmentation procedure, and after code segmentation, execute step a5; a5: Instantiate each component code to be converted according to the code format supported by the vehicle system to obtain executable code, which is recorded as: code to be processed; a6: Construct the output and data transmission method between components in each code combination to be converted; a7: executing the code to be processed in the vehicle system based on the data transmission method; The data transfer method includes: copying the output of the previous component as independent data to the input of the next component; Apply for two spaces, one for storing the initial input of the code combination to be converted, and the other for storing the output of all components. The output of the latter component overwrites the output of the previous component. Apply for a space to cache the output of all components. The output of each component will cover its output. The code segmentation procedure comprises the following steps: b1: Get the serial numbers of all the initial input components in the cache array and sort them in the order of arrival from the smallest to the smallest; Initialize the initial component number j=1; b2: read the jth initial input component and assign its number in the cache array to number i; Initialize an array, recorded as: branch array; b3: Confirm the input of the i+1th component code to be processed; If the input of the i+1th component code to be processed is the same as the output of the ith component code to be processed, it means that the ith component code to be processed and the i-1th component code to be processed have a sequential relationship; execute step b4; Otherwise, it means that the segmentation of this branch code is completed, and step b6 is executed; b4: storing the i-th component code to be processed and the i+1-th code in the branch array in order; i=i+1; b5: Loop through steps b3 to b4; b6: Determine the relationship between j and N; If j is less than N, then j=j+1, and steps b2 to b5 are executed repeatedly; Otherwise, it indicates that the text code to be processed has been processed, and step b7 is executed; b7: Arrange all the branch arrays in the order of segmentation time; Assume there are M branch arrays in total; The data included in each grouping array is recorded as: code combination to be converted; Read all text codes in each code combination to be converted, find all component names, and record them as: components to be converted; b8: Find the input, parameter and output corresponding to each component name according to the component code structure, and record them together with the component name as the component code to be converted; The communication between the encoder and the decoder is based on I 2 C. SPI or socket protocol; The text code is stored and sent based on the txt format.

[0010] The present application provides a decoder for graphics coding of an in-vehicle sadsp system. The encoder on the PC side records the processing logic of all multimedia audio effects and scene effects through text codes in code format and combined code format, and sends the text code to the in-vehicle system for reading based on the decoder. The decoder decodes the code in text format based on the decoding module, and generates executable code supported by the system from the decoded code through the sadsp processing stream generation module. The decoding processing logic in the decoding module is simple and clear, with a small amount of calculation, and can quickly and accurately convert the text code into executable code supported by the in-vehicle system, ensuring that the method is universal and applicable to various forms of in-vehicle systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 It is a schematic diagram of the structure of the adsp system based on software implementation; Figure 2 An example of the encoding process for the encoder; Figure 3 It is the structural diagram of the component; Figure 4 This is an example of a multi-component combination; Figure 5 Example 1 of the process of generating a flow for sadsp processing; Figure 6 Example 2 of the process of generating a flow for sadsp processing; Figure 7 Example 3 of the process of generating flow for sadsp processing; Figure 8 This is an example of parallel processing where multiple data streams exist simultaneously. DETAILED DESCRIPTION

[0012] In the prior art, when the sound effect adjustment parameters corresponding to the hardware chip are converted into graphics code, C code, XML or JSON format files are usually directly generated. 2C or SPI or socket and other protocols to the vehicle system. However, in actual applications, it is found that the data in the form of C code needs to be compiled first, and the sound effect needs to be adjusted 10 times. In order to hear the effect, it needs to be compiled 10 times. The compilation time is very time-consuming and increases the R&D cost; while there are many methods for parsing XML or JSON, which are also open source and have corresponding library functions. However, relying on third-party software increases the complexity of the software and the size of the software. A large amount of memory is required to parse XML or JSON data, which occupies too much system resources and is not suitable for embedded systems with tight system resources. If additional processes are set to solve this problem, the R&D cost will be increased. In order to reduce the occupation of system resources and shorten the R&D time, the code describing the sound effect and scene adjustment is transmitted based on the text in txt format. The text is a universal code-recognizable format, which does not need to rely on third-party parsing and can be parsed through a simple formatted input interface. At the same time, in order to avoid the limitation of hardware chips, our company has implemented a pure software ADSP solution, namely: sadsp (software audio digital signal processor) solution. Compared with traditional technical solutions, this technical solution is implemented in pure software, which is more conducive to platformization. This solution can be deployed on CoreDrive, Qualcomm, MTK or Rising Micro platforms.

[0013] like Figure 1 The figure shows the structure diagram of the vehicle-mounted sadsp system based on software implementation. Figure 1 The system executes the following steps to adjust various multimedia sound effects and scene effects through software.

[0014] S1: Build a sadsp component library, and use the component library to record all the effects that the vehicle multimedia system needs to support; The sadsp component library includes multiple components, each of which implements signal processing functions with different functions; The components include: component input, component output and component parameters; The component input is connected to the external signal input terminal; the component parameter is controlled by the switch mark to control whether it is turned on. When the switch is on, it indicates that the signal entering from the input is processed by the corresponding component parameter. When the switch is off, it indicates that the incoming signal is not processed by the corresponding component parameter; the component output is the corresponding result after the input signal is processed by the component.

[0015] In the specific implementation, a one-to-one correspondence is established between all components in the sadsp component library and the editing modules in the audio data graphic development tool to ensure that all editing effects in the audio data graphic development tool can be recorded based on the sadsp component library.

[0016] All component information is pre-defined based on the component description file and stored in the encoder and decoder to ensure the accuracy of the encoding and decoding process of the encoder and decoder; the component information includes: component name, parameter list and the legal range of each parameter.

[0017] All filters such as lowpass, highpass, allpass, bandpass, bandstop, low-cut filter, high-cut filter, peak filter, notch filter, butterworth filter, or delay, pre-scale, mixer module, etc. can be described based on software components. All components constitute the component library.

[0018] S2: Build component code rules for each component: [input 1, input2, ... input N]component_name[switch, component parameter 1, …, component parameter M][ output]; Among them, N means that the component includes N component inputs, M means that the component includes M component parameters; component_name is the component name; input and output represent the input and output of the component. Component parameters include the original parameters of the component and also support custom parameters.

[0019] like Figure 3 As shown, a component consists of three parts: input, output, and parameters. Take a Butterworth filter as an example. The Butterworth filter is often used in audio signal processing because it has the flattest frequency response. The Butterworth filter is a graphical component.

[0020] Figure 1The f in the string stands for filter. A component can have multiple inputs, multiple outputs, and multiple different parameters. Depending on the component, the inputs, outputs, and parameters may be different, and the number of them may also be different. As for the Butterworth filter component, there are multiple inputs, multiple parameters, and one output. The input represents the signal input end, and the output represents the result after the Butterworth filter is processed. The parameter switch here indicates whether the component is turned on. If it is not turned on, then the link is equivalent to not doing any processing on the signal. This is what is often called bypass in audio processing. The parameters for the Butterworth filter are: Q, quality factor, fc, cutoff frequency, fs, and sampling rate.

[0021] Then generate the following code for the Butterworth filter: [input1, input2, ...inputN]compnent_name[switch, Q, fc, fs][output] As an embodiment, assuming there is a stereo sound source, and a Butterworth low-pass filter is used to process the audio signal at the front end of an EQ, the Butterworth graph will be coded in the following form.

[0022] [inputl, inputr]bwlpf_before_PEQ[enable, 1.0, 10000, 48000][output] Inputl represents the left channel data; inputr represents the right channel data; bwlpf_before_PEQ indicates the component name; Enable means enable, disable means disable; 1.0, 10000, 48000 represent,Q,fc,fs respectively; Output represents the output after Butterworth filter processing, which can be cascaded to the next level of signal processing.

[0023] S3: Construct combination code rules for scenarios where multiple components process signals in sequence: [input] compnent_name 1 [switch, component parameter set][ output component name 1][output component name 1] compnent_name2[switch, component parameter set][ output component name 2][output component name 2]...compnent_namen[switch, component parameter set][output component name n].

[0024] In the formula, the input of the next level is set to be the same as the output of the previous level, indicating that the two signal processing are connected together; n means that the combination includes n components; the component parameter set is: component parameter 1, …, component parameter M. The component code rule also includes: all codes in the same combination are on the same line.

[0025] like Figure 4 As shown in the figure, if an audio is processed by PEQ, PEQ uses a butterworth filter, a peak filter, and a notch filter, which are marked as: bwlpf_before_PEQ, peak_PEQ, and notch_PEQ. This embodiment is for the sake of simplicity of description, and in actual applications, in order to achieve a sound effect or scene adjustment, it may be necessary to process with 9 or 16 segments of filters, but the method and logic of graphic coding itself remain unchanged.

[0026] Multiple components are connected to form a combination operation to realize a sound effect or scene. When the graphics are coded, all the codes in the same combination are on the same line; this makes it easier for the decoder to divide the code into different combinations by line after receiving the data, and then parse the text. When the decoder encounters a line break during execution, it will consider it as another combination link. Figure 1 The technical solution shown supports sending text encodings of multiple sound effects or scenes at the same time, effectively improving data transmission efficiency.

[0027] Figure 4 In the embodiment shown, the corresponding codes are as follows: [input]bwlpf_before_PEQ[enable, 1.0, 10000, 48000][output bw][outputbw]peak_PEQ[enable, 1.0, 10000, 48000, 3.0][output p][outputp]notch_PEQ[enable, 1.0, 16000, 48000, 3.0][output] When an input is the same as the output of another component, it means that the two signals are connected together and the component is the subordinate of the output component.

[0028] S4: Build an encoder and integrate the encoder into an audio data graphic development tool. The audio data graphic development tool includes: a PC terminal and a mobile terminal APP. The audio data graphic development tool is implemented based on any tuning software that adjusts the sound effect based on a graphic method in the prior art, or it can be implemented by developing software by yourself.

[0029] The encoder includes: a sadsp component library and an encoding module; the encoding module tracks the audio data graphic development tool, records each audio effect editing process based on component code rules and combination code rules, and outputs the corresponding code in text format.

[0030] The encoding process of the encoder is as follows Figure 1 and Figure 2 shown.

[0031] By using an encoder to convert graphics into text, the text has more universal characteristics and does not need to rely on third-party parsing software for parsing, making it more universal. After coding, the text code is integrated into the system, and the code in the system directly generates the corresponding signal processing module based on the text. The entire process does not require recompiling the code, and the efficiency of adjustment is greatly improved.

[0032] S5: Build a decoder and embed the decoder into the vehicle system.

[0033] In the technical solution of the present application, the decoder receives the text code sent by the encoder, generates a processing stream code based on the text code, and sends the processing stream code to the signal processing module in the vehicle system for execution. The communication between the encoder and the decoder is based on I 2 C or SPI or socket protocol. The text code is stored and sent based on the txt format.

[0034] The decoder includes: a validity detection module, a decoding module and a sadsp processing flow generation module.

[0035] The validity check performed by the validity detection module includes: The format of the received text code is checked for validity according to the component code rules and combination code rules; the corresponding parameters and the legal rules of the parameters are confirmed according to the component name, and the legality of each parameter is checked; the component names corresponding to all components included in the text code must be in the preset component name definition set; all legal text codes are sent to the decoding module.

[0036] The decoding module decomposes the text code according to each component and obtains the execution data corresponding to each component.

[0037] The sadsp processing flow generation module generates executable code in the form supported by the vehicle system, forms a sadsp processing flow based on the executable code, and sends the sadsp processing flow to the signal processing module in the vehicle system for execution. The sound effects and scene effects adjusted by the tuning software are presented in the vehicle multimedia system.

[0038] Because illegal coded text input may cause program operation abnormalities, such as crash, etc., the generation system must perform legality checks on the input text. The coded text is composed of multiple components, and the code structure of each component is as follows: [input1, input2, ...inputN]compnent_name[switch, Q, fc, fs][output] It consists of input interface, component name, input parameters, and output interface. Any coded text that does not meet the legality of the component will not be processed by the system.

[0039] A component must consist of an input interface, a component name, input parameters, and an output interface. That is, the component code must consist of three complete pairs of []. The first [] is followed by the component name, and [] is a marker that separates different segments of component information. Therefore, none of the parts in [] can appear in the identifier (input interface name, component name, parameter name, output interface name). There cannot be [, and there cannot be []. The switch in the component parameter can only be enable or disable.

[0040] The legality of each input parameter must also be checked. For example, the legal range of Q is: 0-1.0, the legal range of fc is: 20-20k, and the legal range of fs is: 0-96k.

[0041] Component name validity check: The component name must contain a valid component type. The valid component types are predefined, such as bwlpf, bwhpf, bwbpf, bwspf, pf, nf, etc. If the component name does not contain a valid component type, the component name is invalid. Therefore, the processing flow cannot be instantiated.

[0042] For example, the following component coded text is illegal: Error example 1: The input interface list does not have "[": input1, input2, ...inputN]compnent_name[switch, Q, fc, fs][output]; Error example 2: The output interface list does not have "]": [input1, input2, ...inputN]compnent_name[switch, Q, fc, fs][output; Error example 3: The component name contains "]": [input1, input2, ...inputN]compnent_name_][switch, Q, fc, fs][output]; Error example 4: No input list: compnent_name[switch, Q, fc, fs][output] Error example 5: The switch field of the component parameter is not enable or disable: [input1, input2, ...inputN]compnent_name[switch=open, Q, fc, fs][output].

[0043] After the above processing, the legal coded text is sent to the decoding module for the next level of processing and formatting parameter input. The decoding module first reads the coded text by line and stores it in a two-dimensional data, then formats the input according to the line string, and obtains the component type based on the string matching, thereby creating different component modules. Here, the two-dimensional array line length must be careful not to overflow, and overflow detection is required.

[0044] When the decoder receives the text code to be processed, it first reads the code line by line, records each line of code as: text code to be processed, and then analyzes it according to the following steps.

[0045] a1: Traverse all the text codes to be processed and find all component names; a2: According to the component code structure, find the input, parameter and output corresponding to each component name, and record them together with the component name as: component code to be processed; a3: storing all component codes to be processed into a cache array according to their sequence in the text code to be processed; a4: confirm the input included in each component code to be processed; Find all the component codes to be processed that do not include other component names in the input, and record them as: initial input component; Assume that there are N initial input components in total; If N=1, it means that the text code to be processed includes only one complete path. The text code to be processed is recorded as: code combination to be converted, and all components included in it are recorded as: components to be converted; execute step a12; Otherwise, execute step a5; a5: Get the serial numbers of all the initial input components in the cache array and sort them in the order of arrival from the smallest to the smallest; Initialize the initial component number j=1; a6: read the jth initial input component, and assign its number in the cache array to number i; Initialize an array, recorded as: branch array; a7: Confirm the input of the i+1th component code to be processed; If the input of the i+1th component code to be processed is the same as the output of the ith component code to be processed, it means that the ith component code to be processed and the i-1th component code to be processed have a sequential relationship; execute step a8; Otherwise, it means that the segmentation of this branch code is completed, and step a10 is executed; a8: storing the i-th component code to be processed and the i+1-th code in the branch array in order; i=i+1; a9: Loop through steps a7 to a8; a10: Determine the relationship between j and N; If j is less than N, then j=j+1, and steps a6 to a9 are executed repeatedly; Otherwise, it indicates that the text code to be processed has been processed, and step a11 is executed; a11: Arrange all the branch arrays in the order of segmentation time; Assume there are M branch arrays in total; The data included in each grouping array is recorded as: code combination to be converted; Read all text codes in each code combination to be converted, find all component names, and record them as: components to be converted; a12: find the input, parameter and output corresponding to each component name according to the component code structure, and record them together with the component name as the component code to be converted; a13: Instantiate each component code to be converted according to the code format supported by the vehicle system to obtain executable code, which is recorded as: code to be processed; In this application, component actions are recorded based on the component format, which can cover all situations. After obtaining each component and its input, output and parameters, they are converted into executable codes supported by the vehicle system based on the coding protocol supported by the vehicle system, ensuring that this application is applicable to all vehicle systems. a14: Construct the output and data transmission method between components in each code combination to be converted; a15: Based on the data transmission method, the code to be processed is executed in the vehicle system.

[0046] The decoder in this application decodes the code in text format. The processing logic is simple and clear, with a small amount of calculation. It can quickly and accurately convert the text code into executable code supported by the vehicle system, ensuring that this application is universal and suitable for various forms of vehicle systems.

[0047] Code example for component combination: [input]bwlpf_before_PEQ[enable, 1.0, 10000, 48000][output bw][outputbw]pf_PEQ[enable, 1.0, 10000, 48000, 3.0][output p][output p]nf_PEQ[enable, 1.0, 16000, 48000, 3.0][output].

[0048] All the codes in this text code are located on the same line. It can be seen that it only includes one execution branch, which corresponds to a sadsp processing flow; this sadsp processing flow contains three components, the component types are butterworth low-pass filter, a peak filter, and a notch filter, and obtains the corresponding parameters.

[0049] bwlpf_before_PEQ[enable, 1.0, 10000, 48000], pf_PEQ[enable, 1.0, 10000, 48000, 3.0], nf_PEQ[enable, 1.0, 16000, 48000, 3.0]; Adsp processing flow generation: According to the component parameters obtained above, the component is implemented.

[0050] As an example, there is the following pseudo code: Bwlpf_init(input, output, size); Peakf_init(input, output, size); Notchf_init(input, output, size); Based on the connection relationship of the above processing flow, the following is generated: Figure 5 The processing flow calling relationship is shown as follows: Figure 5 The following pseudo code is based on the purpose of better expressing the process of sadsp processing stream processing and the process of sadsp processing stream generation.

[0051] Bwlpf_proc(input, output bw, size); Peakf_proc(input pf, output pf, size); Notchf_proc(input nf, output nf, size).

[0052] Figure 5 The process shown in the figure involves two data copies, namely, Figure 5 In the data transmission method of execution, the output of the previous component is copied as independent data to the input of the next component.

[0053] and Figure 6 In the data transfer method shown, two spaces are applied, one for storing the initial input of the code combination to be converted, and the other for storing the output of all components. The output of the latter component overwrites the output of the former component. The input of the code is kept separately, and when other key data is processed, the data after processing the processing stream overwrites the original data, so that data copy is not required. Finally, one of the two data spaces stores the input data and the other stores the final output data.

[0054] Alternatively, apply for a space to cache the input and output of all components, and the output of each component covers its input; Figure 7 As shown, in this processing method, there is no need to copy data, and the processed data is saved in the original data location.

[0055] The specific data processing method you choose depends on the requirements for the input data, intermediate data, or output data of each execution branch in the multi-cascade system. If you only need to use the final output data of each execution branch in the multi-cascade system, then choose Figure 7 If you need to use the input data of each execution branch later, you can choose Figure 6This application defines three data processing methods to ensure that the needs of most practical application scenarios can be met.

[0056] Above Figure 5 , Figure 6 and Figure 7 , are examples of generating executable codes for the signal processing module in the vehicle system in the sadsp processing stream generation module. The specific code conversion process and details are adaptively adjusted according to the logic of the original signal processing module in the vehicle system. The specific implementation of the encoder and decoder can be developed based on the existing technology and embedded into the original software and vehicle system according to the specific support of the audio data graphics development tool and the vehicle system.

[0057] In the sadsp processing flow generation module, there may be parallel processing of multiple data streams at the same time. As an example, Figure 8 The graphical code shown is a channel repair module. The main function of the channel repair module is to repair the frequency response of a stereo audio data. Each data will have several filters (components).

[0058] based on Figure 8 It can be seen that there are 5 execution branches (sadsp processing flow) from top to bottom, each execution branch corresponds to a repair of stereo audio data; each execution branch includes two input data: ch l and ch r, representing the left and right channels respectively; each execution branch includes: 5 filters filter1~filter5 connected in sequence, each filter corresponds to a frequency point; the delay module connected after the 5 filters, the delay time defined in the delay module defines the sound delay of this channel in milliseconds and is sent to the subsequent mixing module. The delay time of the five branches is set at different times to obtain a stereo surround effect; the output of the five delay modules is sent to the switch controller ON / OFF, and after passing through the switch controller, it is sent to the left channel mixing module and the right channel mixing module for mixing.

[0059] Among them, there are 5 filters for the sadsp data flow of one of the execution branches: [input]filter_level1[enable, 1.0, 400, 48000][output f1]; [input]filter_level2[enable, 1.0, 800, 48000][output f2]; [input]filter_level3[enable, 1.0, 1000, 48000][output f3]; [input]filter_level4[enable, 1.0, 1200, 48000][output f4]; [input]filter_level5[enable, 1.0, 1600, 48000][output f5]; After the filter processing, there is a delay module: [output f1]delay1[0][output d1]; [output f2]delay2[0][output d2]; [output f3]delay3[0][output d3]; [output f4]delay4[0][output d4]; [output f5]delay5[0][output d5]; In this embodiment, the switch controller ON / OFF is on, and all delay module output data is directly sent to the mixing module for mixing processing: Mix the L output of the delay module and output it to the L channel mixing module: [output d1 L]mixer_L[0.5][output L]; [output d2 L]mixer_L[0.5][output L]; [output d3 L]mixer_L[0.5][output L]; [output d4 L]mixer_L[0.5][output L]; [output d5 L]mixer_L[0.5][output L]; Mix the R output of the delay module and output it to the R channel mixing module: [output d1 R]mixer_R[0.5][output R]; [output d2 R]mixer_R[0.5][output R]; [output d3 R]mixer_R[0.5][output R]; [output d4 R]mixer_R[0.5][output R]; [output d5 R]mixer_R[0.5][output R]; Through the above coding processing, the audio data stream of a channel repair module can be described, and more complex ADP topologies can be extended from this, thereby realizing the abstraction of ADP.

[0060] Figure 8 This is just an example of a simple graphics code development. In fact, in audio effect development, one execution branch may include dozens of components, or may include more than a dozen execution branches. Each audio effect development can realize the textualization of graphics code development based on the encoder, and send the text code to the decoder in this application for code segmentation and conversion into executable code supported by the vehicle system. The whole process has a small amount of calculation, high execution efficiency, and versatility.

[0061] After using the technical solution of the application, the sound effects and scene effects of the multimedia system in the intelligent vehicle are adjusted based on the SadSP solution. Compared with the traditional technical solution, this technical solution is implemented by pure software, which is more conducive to platformization. Whether it is Xinchi, Qualcomm, MTK, Rising Micro Platform, etc., it can be deployed. With the development of semiconductor technology and the improvement of computing power, the execution efficiency of this application is also sufficient to meet the real-time requirements of intelligent vehicles. This application reduces the complexity of the system and saves system development time, and has more market prospects and technical value.

Claims

1. A decoder for graphics coding of a vehicle-mounted sadsp system, characterized in that: It includes: a decoding module and a sadsp processing flow generation module; After receiving the text code sent by the encoder, the decoder sends all legal text codes to the decoding module; The decoding module decomposes the text code according to each of the components to obtain execution data corresponding to each of the components; The sadsp processing flow generation module generates executable codes in a form supported by the vehicle-mounted system, constructs the sadsp processing flow based on the executable codes, and sends the sadsp processing flow to the signal processing module in the vehicle-mounted system for execution; A processing flow code is generated based on the text code, and the processing flow code is sent to a signal processing module in the vehicle system for execution.

2. The decoder for graphics coding of a vehicle-mounted sadsp system according to claim 1, characterized in that: It also includes: a validity detection module; The validity check contents performed based on the validity detection module include: The format of the received text code is checked for validity according to the component code rules and the combination code rules; the corresponding parameters and the legal rules of the parameters are confirmed according to the component name, and the legality of each parameter is checked; the component names corresponding to all components included in the text code must be in the preset component name definition set.

3. The decoder for graphics coding of a vehicle-mounted sadsp system according to claim 1, characterized in that: The decoder also includes a component description file; The component description file contains the component information of all legal components: The component information includes: component name, parameter list and legal range of each parameter.

4. The decoder for graphics coding of a vehicle-mounted sadsp system according to claim 1, characterized in that: When the decoder receives the text code to be processed, it analyzes and decodes it according to the following steps: a1: Traverse all the text codes to be processed and find all component names; a2: According to the component code structure, find the input, parameter and output corresponding to each component name, and record them together with the component name as: component code to be processed; a3: storing all component codes to be processed into a cache array according to their sequence in the text code to be processed; a4: confirm the input included in each component code to be processed; Find all the component codes to be processed that do not include other component names in the input, and record them as: initial input component; Assume that there are N initial input components in total; If N=1, it means that the text code to be processed includes only one complete path. The text code to be processed is recorded as: code combination to be converted, and all components included in it are recorded as: components to be converted; Execute step a5; Otherwise, execute the code segmentation procedure, and after code segmentation, execute step a5; a5: Instantiate each component code to be converted according to the code format supported by the vehicle system to obtain executable code, which is recorded as: code to be processed; a6: Construct the output and data transmission method between components in each code combination to be converted; a7: Based on the data transmission method, execute the code to be processed in the vehicle system.

5. The decoder for graphics coding of a vehicle-mounted sadsp system according to claim 4, characterized in that: The data transfer method includes: copying the output of the previous component as independent data to the input of the next component; Apply for two spaces, one for storing the initial input of the code combination to be converted, and the other for storing the output of all components. The output of the latter component overwrites the output of the previous component. Apply for a space to cache the output of all components. The output of each component covers its output.

6. The decoder for graphics coding of a vehicle-mounted sadsp system according to claim 4, characterized in that: The code segmentation procedure comprises the following steps: b1: Get the serial numbers of all the initial input components in the cache array and sort them in the order of arrival from the smallest to the smallest; Initialize the initial component number j=1; b2: read the jth initial input component and assign its number in the cache array to number i; Initialize an array, recorded as: branch array; b3: Confirm the input of the i+1th component code to be processed; If the input of the i+1th component code to be processed is the same as the output of the ith component code to be processed, it means that the ith component code to be processed and the i-1th component code to be processed have a sequential relationship; execute step b4; Otherwise, it means that the segmentation of this branch code is completed, and step b6 is executed; b4: storing the i-th component code to be processed and the i+1-th code in the branch array in order; i=i+1; b5: Loop through steps b3 to b4; b6: Determine the relationship between j and N; If j is less than N, then j=j+1, and steps b2 to b5 are executed repeatedly; Otherwise, it indicates that the text code to be processed has been processed, and step b7 is executed; b7: Arrange all the branch arrays in the order of segmentation time; Assume there are M branch arrays in total; The data included in each grouping array is recorded as: code combination to be converted; Read all text codes in each code combination to be converted, find all component names, and record them as: components to be converted; b8: Find the input, parameter and output corresponding to each component name according to the component code structure, and record them together with the component name as the component code to be converted.

7. The decoder for graphics coding of a vehicle-mounted sadsp system according to claim 1, characterized in that: The communication between the encoder and the decoder is based on I 2 C. SPI or socket protocol.

8. The decoder for graphics coding of a vehicle-mounted sadsp system according to claim 1, characterized in that: The text code is stored and sent based on the txt format.

Images