WO2011061878A1 - マルチコアシステム、マルチコアシステムの制御方法及びプログラムが格納された非一時的な可読媒体 - Google Patents

マルチコアシステム、マルチコアシステムの制御方法及びプログラムが格納された非一時的な可読媒体 Download PDF

Info

Publication number
WO2011061878A1
WO2011061878A1 PCT/JP2010/004911 JP2010004911W WO2011061878A1 WO 2011061878 A1 WO2011061878 A1 WO 2011061878A1 JP 2010004911 W JP2010004911 W JP 2010004911W WO 2011061878 A1 WO2011061878 A1 WO 2011061878A1
Authority
WO
WIPO (PCT)
Prior art keywords
program
dma transfer
synthesized
data
audio data
Prior art date
Application number
PCT/JP2010/004911
Other languages
English (en)
French (fr)
Inventor
賢太郎 笹川
Original Assignee
日本電気株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電気株式会社 filed Critical 日本電気株式会社
Priority to US13/502,601 priority Critical patent/US8892230B2/en
Priority to JP2011541787A priority patent/JP5382133B2/ja
Priority to CN201080052247.8A priority patent/CN102667745B/zh
Publication of WO2011061878A1 publication Critical patent/WO2011061878A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2038—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with a single idle spare processing component
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2043—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share a common memory address space
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/20—Handling requests for interconnection or transfer for access to input/output bus
    • G06F13/28—Handling requests for interconnection or transfer for access to input/output bus using burst mode transfer, e.g. direct memory access DMA, cycle steal
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/10527—Audio or video recording; Data buffering arrangements
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/02—Editing, e.g. varying the order of information signals recorded on, or reproduced from, record carriers
    • G11B27/031—Electronic editing of digitised analogue information signals, e.g. audio or video signals
    • G11B27/034—Electronic editing of digitised analogue information signals, e.g. audio or video signals on discs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2028—Failover techniques eliminating a faulty processor or activating a spare
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2033—Failover techniques switching over of hardware resources
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/10527—Audio or video recording; Data buffering arrangements
    • G11B2020/1062—Data buffering arrangements, e.g. recording or playback buffers
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/10527—Audio or video recording; Data buffering arrangements
    • G11B2020/1062—Data buffering arrangements, e.g. recording or playback buffers
    • G11B2020/10629—Data buffering arrangements, e.g. recording or playback buffers the buffer having a specific structure
    • G11B2020/10638—First-in-first-out memories [FIFO] buffers
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/10527—Audio or video recording; Data buffering arrangements
    • G11B2020/1062—Data buffering arrangements, e.g. recording or playback buffers
    • G11B2020/10675—Data buffering arrangements, e.g. recording or playback buffers aspects of buffer control
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/10527—Audio or video recording; Data buffering arrangements
    • G11B2020/1062—Data buffering arrangements, e.g. recording or playback buffers
    • G11B2020/10675—Data buffering arrangements, e.g. recording or playback buffers aspects of buffer control
    • G11B2020/1074—Data buffering arrangements, e.g. recording or playback buffers aspects of buffer control involving a specific threshold value
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10—Digital recording or reproducing
    • G11B20/10527—Audio or video recording; Data buffering arrangements
    • G11B2020/1062—Data buffering arrangements, e.g. recording or playback buffers
    • G11B2020/10814—Data buffering arrangements, e.g. recording or playback buffers involving specific measures to prevent a buffer underrun

Definitions

  • the present invention relates to a multi-core system, a control method for the multi-core system, and a non-transitory readable medium storing a program.
  • MPU Micro Processing Units
  • CPU Central Processing Unit
  • IRQ Interrupt ⁇ ⁇ ⁇ ⁇ ReQuest
  • the MPU can set which interrupt request is assigned to which CPU core based on the register setting.
  • a technique is known in which audio data is transferred from a CPU in the MPU 50 to an ADAC (Audio DAC) 51 via an I2S (Inter-IC Sound) bus.
  • the sound data is, for example, PCM (Pulse Code Modulation) sound.
  • I2S is a serial communication format manufactured by PHILIPS (registered trademark), which constitutes an interface device for audio data.
  • PCM audio and compressed audio ⁇ -law, ADPCM, etc.
  • an I2C (Inter-Integrated Circuit) bus is a device control serial bus developed by PHILIPS (registered trademark).
  • the ADAC 51 converts audio data into stereo audio.
  • the DAC is a D / A converter. Analog sound (stereo) output from the ADAC 51 is reproduced on the speaker.
  • an I2S device having a FIFO (First In In First Out) buffer is known.
  • Such an I2C device dequeues the audio data stored in the FIFO buffer and outputs it to the ADAC via the I2S bus.
  • an I2S that can generate an interrupt hereinafter referred to as “FIFO boundary interrupt”.
  • FIFO boundary interrupt There is a device. Generally, this interrupt is used for PIO (Programmed Input / Output) transfer.
  • the applicant of the present application discloses a technique for operating a plurality of OSs on a single multi-core CPU in Japanese Patent Application No. 2009-190103 filed earlier.
  • this technique when an I2C device is shared by the plurality of OSs, even if the OS that controls the I2S device becomes inoperable due to kernel panic or freeze, the other OS can control the I2C device. Thereby, occurrence of sound interruption can be prevented with a simple configuration.
  • FIG. 9A shows the flow of audio data and processing.
  • the OS on the main system side operates by using a DMA transfer completion interrupt as a trigger, and performs audio data audio mixing processing and DMA transfer request processing. Thereby, the audio data after the audio mixing processing is DMA-transferred to the FIFO.
  • a plurality of OSs receive a DMA (Direct Memory Access) transfer interrupt.
  • the OS on the standby side operates using a DMA transfer completion interrupt as a trigger, and sets an HW (Hardware) timer.
  • the OS on the main system side performs the audio mixing processing of the audio data and the DMA transfer request processing to cancel the HW timer.
  • the OS on the main system side becomes inoperable by the timeout of the HW timer.
  • the HW timer times out, the OS on the main system side becomes inoperable. Therefore, the OS on the main system side is switched to the OS on the standby system side, and the audio mixing process and the DMA transfer request process are continued. This prevents the FIFO buffer from becoming empty and causing sound interruptions.
  • the standby-side OS that detects the inoperability of the primary-side OS continuously performs voice mixing processing or the like on behalf of the primary-side OS.
  • a processing method of a DMA transfer interrupt thread for performing audio mixing processing or the like can be selected according to reception of a DMA transfer completion interrupt. Yes.
  • one of the processing methods of patterns A and B is selected according to the magnitude relationship between the audio mixing processing time and the DMA transfer interval ( ⁇ I2S underrun error occurrence time).
  • the audio mixing processing time and the DMA transfer interval can be calculated from the specifications of the mounting environment.
  • the specifications of the mounting environment are, for example, the number of FIFO buffers of the I2S device, the audio sampling frequency, the DMA transfer size, and the CPU clock.
  • FIG. 9B shows the relationship between the audio mixing processing time and the I2S underrun error occurrence time under the selection conditions of patterns A and B.
  • pattern A is selected.
  • a DMA transfer start request process is performed following the audio mixing process.
  • the HW timer after the audio mixing process by the main OS is not canceled and the OS is switched to the standby OS, and after the audio mixing process is performed by the standby OS, the DMA transfer is performed. This is because the DMA transfer can be performed before the I2S underrun error occurrence time elapses.
  • pattern B is selected.
  • the audio mixing process is performed following the DMA transfer start request process.
  • this condition is met, the HW timer after the audio mixing process by the main OS is not canceled and the OS is switched to the standby OS, and after the audio mixing process is performed by the standby OS, the DMA transfer is performed. This is because the DMA transfer is performed after the I2S underrun error occurrence time elapses.
  • the DMA transfer start request process is performed before the audio mixing process. Therefore, as shown in FIG. 10, the audio data is prepared by prefetching one packet (DMA transfer size). That is, the audio data is double buffered. However, in pattern B, the audio data is prefetched for one packet. Therefore, when playing a video with a video player that performs image and sound synchronization, the audio data that is actually being played and the audio data that the video player recognizes as being played are shifted by one packet, which reduces the accuracy of the image and sound synchronization. There was a problem of doing.
  • FIG. 11 illustrates a case where the OS on the main system side is OS 72 and the OS on the standby system side is OS 71.
  • the OS 71 has a mixed counter 712.
  • the OS 72 has a mixed counter 722.
  • an application program (hereinafter, abbreviated as “APP” in the figure) 721 that operates on the OS 72 on the main system side enqueues audio data into the sound queue 82.
  • the application program 721 reproduces a moving image having a sampling frequency of 48000 Hz and including 16-bit stereo sound.
  • the application program 721 sends out audio data, for example, in units of 4096 bytes and at intervals of (1024/48000) seconds.
  • the software mixer 723 operating on the OS 72 on the main system side mixes the audio data dequeued from the sound queues 81 and 82.
  • the software mixer 723 stores the audio data after mixing in the DMA transfer buffer 73 as audio data for DMA transfer.
  • the audio data stored in the DMA transfer buffer 73 is transferred to the FIFO 74 of the I2S device.
  • the audio data dequeued from the FIFO 74 is reproduced by the ADAC 75.
  • the software mixer 723 converts audio data having different sampling frequencies and quantization bits output from a plurality of application programs into single audio data. Each time the audio mixer mixes the audio data, the software mixer 723 counts up the counter value of the mixed sample counter 722 by the number of samples of the audio data generated by mixing.
  • the application program 721 operating on the OS 72 on the main system side refers to the counter value of the mixed sample number counter 722 to calculate the transmission interval of the audio data and synchronize the image sound. That is, the application program 721 reproduces an image corresponding to the number of samples of audio data that has been mixed when reproducing a moving image by performing image and sound synchronization. Therefore, in the processing method in which the audio data is prefetched for one packet and mixed as in the pattern B, the reproduced image is greatly deviated from the sound that is actually output, and the accuracy of the image and sound synchronization is lowered. End up.
  • an object of the present invention is to provide a multi-core system, a control method for a multi-core system, and a program capable of preventing the occurrence of sound interruption while suppressing a decrease in accuracy of image and sound synchronization. That is.
  • the multi-core system operates on the first processor core, mixes the first and second audio data, and stores the mixed synthesized audio data in the DMA transfer buffer.
  • the main system program, the standby system program that operates on the second processor core and operates as a backup system of the main system program, and the synthesized voice data transferred from the DMA transfer buffer are sequentially stored and stored.
  • a voice output unit that reproduces the synthesized voice data, and the standby program stores the synthesized voice data stored in the voice output unit in a storage amount of the synthesized voice data stored in the DMA transfer buffer. If the predetermined data amount determined according to the amount has not been reached, mixing of the synthesized speech data executed by the main program and By taking over the paid and executes.
  • the control method of the multi-core system operates on the first processor core, mixes the first and second audio data, and transfers the mixed synthesized audio data to the DMA transfer buffer.
  • a main system program stored in the first processor core a standby system program operating on the second processor core and operating as a standby system of the main system program, and synthesized voice data transferred from the DMA transfer buffer.
  • a multi-core system control method comprising: an audio output unit that reproduces the stored synthesized audio data; and a storage amount of the synthesized audio data stored in the DMA transfer buffer is stored in the audio output unit.
  • the program according to the third aspect of the present invention sequentially stores the synthesized voice data to be transferred, and DMA transfer for storing the synthesized voice data to be transferred to the voice output unit for reproducing the stored synthesized voice data.
  • a standby program that operates as a standby system for the main program on a processor core different from the main program that stores synthesized voice data obtained by mixing the first and second audio data in the buffer. Determining whether the amount of synthesized voice data stored in the DMA transfer buffer reaches a predetermined data amount determined according to the amount of synthesized voice data stored in the voice output unit And when it is determined that the predetermined amount of data has been reached, the standby system program executes the synthesized speech data that was executed by the main system program. And performing by taking over the mixing and storage of data, the characterized in that to be executed by the processor core.
  • FIG. 10 is a sequence diagram for explaining audio mixing processing and DMA transfer processing in a state where the main system OS according to the embodiment of the present invention is operating normally.
  • FIG. 10 is a sequence diagram for explaining audio mixing processing and DMA transfer processing in a state where the main-system OS according to the embodiment of the present invention becomes inoperable.
  • FIG. 1 is a block diagram showing an outline of the hardware configuration of the multi-core system according to the present embodiment.
  • the multi-core system 2 includes processor cores 61 and 62, a DMA transfer buffer 63, and an audio output unit 64.
  • the processor core 61 operates a program 610 that operates as a main system.
  • the processor core 62 operates a program 620 that operates as a standby system.
  • the DMA transfer buffer 63 stores the synthesized voice data mixed by the programs 61 and 62.
  • the voice output unit 64 sequentially stores the synthesized voice data transferred from the DMA transfer buffer 63 and reproduces the stored synthesized voice data.
  • the program 610 mixes the first and second audio data, and stores the mixed synthesized audio data in the DMA transfer buffer 63.
  • the program 61 is a program that operates as a main system.
  • the program 620 operates as a standby system for the main program.
  • the main program 610 mixes the first and second audio data and stores the mixed synthesized audio data in the DMA transfer buffer 63.
  • the synthesized voice data stored in the DMA transfer buffer 63 reaches a certain amount of data
  • the synthesized voice data stored in the DMA transfer buffer 63 is transferred to the voice output unit 64.
  • the voice output unit 64 sequentially stores the synthesized voice data transferred from the DMA transfer buffer 63 and reproduces the stored synthesized voice data.
  • the standby program 620 determines whether the amount of synthesized voice data stored in the DMA transfer buffer 63 has reached a predetermined data amount determined according to the amount of synthesized voice data stored in the voice output unit 64. Determine whether or not. If the predetermined amount of data has not been reached, the main program 610 takes over and executes the mixing and storage of the synthesized voice data that was executed 610.
  • FIG. 2 is a block diagram showing a hardware configuration of the multi-core system according to the present embodiment.
  • the multi-core system 1 includes a built-in MPU 10, an audio output device 20, and an SDRAM (Synchronous Dynamic Random Access Memory) 30.
  • the SDRAM functions as an external shared memory.
  • the MPU 10 is an integrated circuit (IC) in which a multi-core CPU and peripheral devices (I2S device 13, I2C device 14, and DMAC 15) are integrated into one chip.
  • Each of the CPUs 11 and 12 includes one or a plurality of CPU cores.
  • the CPU 11 includes one CPU core
  • the CPU 12 includes three CPU cores.
  • the CPUs 11 and 12 may be composed of a plurality of multi-core CPUs.
  • the CPU core corresponds to the processor cores 61 and 62.
  • the MPU 10 operates a plurality of OSs on the multi-core CPU.
  • the OS 110 operates on the CPU 11.
  • the OS 120 operates on the CPU 12.
  • the OS 110 and the OS 120 are different types of OSs.
  • the OS 110 is a real-time OS such as ⁇ ITRON and the OS 120 is a high function embedded OS.
  • the high function embedded OS is, for example, embedded Linux (registered trademark) or Windows® CE (registered trademark).
  • an application program 111 (abbreviated as “APP” in the drawing) and a sound driver 112 which is a device driver operate. Audio data output from the application program 111 is input to the sound driver 112.
  • application programs 121, 122, and 123 (in the drawing, abbreviated as “APP”, respectively), a sound server 124, and a sound driver 125 that is a device driver operate.
  • the audio data output from the application program 121 and the application program 122 is input to the sound server 124.
  • the sound data output from the sound server 124 and the sound data output from the application program 123 are input to the sound driver 125.
  • the I2S device 13 transmits audio data to the ADAC & AMP 21 via the I2S bus (I2S bus).
  • the I2S device 13 is a one-system device.
  • the I2S device 13 includes a FIFO 131.
  • the I2S device 13 stores audio data in the FIFO 131.
  • the I2S device 13 handles stereo PCM as audio data.
  • the I2C device 14 is a serial bus for device control.
  • the I2C device 14 is used for reading from and writing to a register included in the ADAC.
  • a DMAC (DMA Controller) 15 controls DMA transfer between the SDARM 30 connected to the outside of the MPU 10 and other devices.
  • audio data is transferred from the inter-OS shared memory 40 on the SDRAM 30 to the FIFO 131 of the I2S device 13 using one channel of the DMAC 15.
  • the sound driver 125 on the OS 120 side normally controls audio mixing processing and peripheral devices (I2S device 13, I2C device 14, and DMAC 15).
  • the audio output device 20 includes an ADAC & AMP 21 and a speaker 22.
  • the ADAC & AMP 21 constitutes an external interface of the audio output device 20.
  • the ADAC & AMP 21 converts and amplifies audio data transmitted via the I2S bus into an analog signal.
  • the ADAC & AMP 21 reproduces an analog signal using the speaker 22.
  • the I2S device 13 and the audio output device 20 correspond to the audio output unit 64.
  • the SDRAM 30 is a volatile memory (RAM) connected to the outside of the MPU 10 via a bus.
  • RAM volatile memory
  • a memory space shared by the OS of the MPU 10 is secured as the OS shared memory 40.
  • a sound queue (sound queue 41, sound queue 42, sound queue 43) and a DMA transfer buffer 44 are set.
  • the sound cue is a ring buffer that stores audio data output by the application program.
  • a number of cues corresponding to the number of application programs that output audio data are created as sound cues.
  • three sound cues (sound cue 41, sound cue 42, and sound cue 43) corresponding to the application program 111 of OS 110, the sound server 124 of OS 120, and the application program 123 of OS 120 are created.
  • the sound data of the sound cues (sound cues 41, sound cues 42, and sound cues 43) are subjected to sound mixing processing and then stored in the DMA transfer buffer 44.
  • the sound cue may be configured using cueing means other than the ring buffer.
  • FIG. 3 is a block diagram showing a functional configuration of the multi-core system according to the present embodiment.
  • the sound driver 112 shown in FIG. 2 is divided into a higher application I / F unit 113 and a driver core unit 114. Further, the sound driver 125 is divided into a higher application I / F unit 126 and a driver core unit 127.
  • the upper application I / F unit 113 has a sampling rate conversion function 116.
  • the upper application I / F unit 126 has a sampling rate conversion function 130.
  • the upper application I / F unit 113 stores the audio data output from the application program 111 in the sound queue 41 in the inter-OS shared memory 40.
  • the sampling rate conversion function 116 of the upper application I / F unit 113 performs sampling rate conversion and quantization bit number conversion on the audio data received from the application program 111 as necessary.
  • the upper application I / F unit 113 stores the converted audio data in the sound queue 41 in the inter-OS shared memory 40.
  • the upper application I / F unit 126 stores the audio data output from the sound server 124 and the application program 123 in the sound queues 42 and 43 in the inter-OS shared memory 40.
  • the sampling rate conversion function 130 of the upper application I / F unit 126 needs to convert the sampling rate and the quantization bit number for the audio data received from the sound server 124 and the application program 123. Do it accordingly.
  • the upper application I / F unit 126 stores the converted audio data in the sound queues 42 and 43 in the inter-OS shared memory 40.
  • the sampling rate conversion functions 116 and 130 convert, for example, 48 kHz 23 bit sound into 44.1 kHz 16 bit sound.
  • the driver core units 114 and 127 mix audio data stored in each sound queue of the inter-OS shared memory 40.
  • the driver core units 114 and 127 transfer the audio data after the audio mixing process to the FIFO 131 of the I2S device 13 using DMA transfer.
  • a functional part that is a part of the sound drivers 112 and 125 and controls the audio mixing processing and the I2S device 13 and the I2C device 14 is defined as the driver core units 114 and 125.
  • audio data output from a plurality of application programs running on each OS is mixed and copied to a DMA transfer area (DMA transfer buffer 44) as a single audio data. Refers to processing.
  • DMA transfer buffer 44 DMA transfer buffer 44
  • the driver core unit of one OS (main system) among a plurality of OSs operates during system operation.
  • the other driver core units of the OS (standby system) are normally in a standby state.
  • the standby system operates only when the OS on the main system side performs a kernel panic or freeze.
  • the main system refers to a system having a driver core unit that operates in a normal state.
  • the standby system refers to a system having a driver core unit that operates when the main system becomes inoperable.
  • the main system and the standby system are the main system and the standby system for the sound reproduction function (part of the function of the sound driver), and are not the main system OS and the standby system OS. That is, the OS on the standby system side refers to an OS having a function as a backup system related to the sound reproduction function.
  • the software mixer 128 is a function called by the driver core unit 127.
  • the software mixer 128 mixes the audio data stored in each sound cue.
  • the software mixer 128 stores the audio data after mixing in the DMA transfer buffer 44.
  • the common interrupt control unit 16 allocates an interrupt request (IRQ) to each CPU core.
  • IRQ interrupt request
  • the common interrupt control unit 16 is basically provided as a hardware function in the MPU 10. If the common interrupt control unit 16 is not installed as a hardware function in the MPU 10, it can be implemented as a software function.
  • Interrupt requests input to the common interrupt control unit 16 are a DMA transfer completion interrupt issued by the DMAC 15 and a FIFO boundary interrupt issued by the I2S device 13 when the DMA transfer of audio data is completed. If there is no DMA transfer request within a certain time from the occurrence of the DMA transfer completion interrupt, the buffer of the FIFO 131 of the I2S device 13 becomes empty and an I2S underrun error occurs.
  • the driver management unit 115 is a function group called by the interrupt handler of the OS on the standby side.
  • the driver management unit 115 performs a switching process for setting the HW timer 17, setting the FIFO boundary interrupt ON / OFF, and switching the operation using the main driver core unit to the operation using the standby driver core unit.
  • the HW timer 17 refers to a hardware timer provided in the MPU 10.
  • the plurality of OSs 110 and 120 receive a DMA transfer completion interrupt.
  • the received DMA transfer completion interrupt reaches the DMA transfer completion interrupt thread 129.
  • the DMA transfer completion interrupt thread 129 operates using a voice data DMA transfer completion interrupt as a trigger, and performs voice data voice mixing processing and DMA transfer request processing.
  • the audio data after the audio mixing process stored in the DMA transfer buffer 44 is DMA-transferred from the SDRAM 30 to the FIFO 131.
  • either the pattern A or the pattern B is selected based on the relationship between the audio mixing process time and the I2S underrun error in the OS 120 on the main system side. .
  • pattern A is selected.
  • the processing is performed in the order of performing the DMA transfer start request processing following the audio mixing processing. That is, in this case, voice mixing processing is performed prior to DMA transfer start request processing.
  • pattern B is selected.
  • the processing is performed in the order of performing the audio mixing processing following the DMA transfer start request processing. That is, in this case, a DMA transfer start request process is performed prior to the audio mixing process.
  • a double buffering process for audio data is required.
  • the selection condition “voice mixing processing time ⁇ DMA transfer interval ⁇ (voice mixing processing time ⁇ 2)” when the selection condition “voice mixing processing time ⁇ DMA transfer interval ⁇ (voice mixing processing time ⁇ 2)” is satisfied, the selection condition “DMA transfer interval ⁇ (voice mixing processing time ⁇ 2)”. "Is satisfied, the pattern A is selected. That is, the selection conditions for pattern B are exactly “voice mixing processing time ⁇ DMA transfer interval” and “DMA transfer interval ⁇ (voice mixing processing time ⁇ 2)”.
  • the monitoring function of the OS 120 on the main system side of the multi-core system according to the embodiment of the present invention will be described.
  • the pattern A is selected when the selection condition “DMA transfer interval> (voice mixing processing time ⁇ 2)” and the pattern B are selected will be described.
  • the driver management unit 115 operated by the interrupt handler included in the standby-side OS 110 sets the HW timer 17.
  • the DMA transfer completion interrupt reaches the DMA transfer completion interrupt thread 129 of the OS 120 on the primary system side
  • the DMA transfer completion interrupt thread 129 releases the set HW timer 17.
  • the set HW timer 17 times out without being released. Therefore, it becomes possible to monitor the inoperability of the OS 120 on the main system side based on the presence or absence of timeout of the HW timer 17.
  • the driver management unit 115 operated by the interrupt handler included in the OS 110 on the standby side permits reception of the FIFO boundary interrupt of the I2S device 13.
  • the driver management unit 115 determines whether the number of audio data samples stored in the DMA transfer buffer 44 has reached a predetermined threshold value. . As a result of the determination, if the number of audio data samples does not reach a predetermined threshold calculated from the number of audio data samples stored in the FIFO 131, the driver management unit 115 uses the main driver core unit 127. A switching process for switching the operation to the operation using the spare driver core unit 114 is performed.
  • the predetermined threshold is the number of samples of audio that can complete the execution of the remaining audio mixing processing and DMA transfer request processing until all the remaining audio data stored in the FIFO 131 is dequeued.
  • This is a reference value for determining whether data is stored in the DMA transfer buffer 44. That is, if the number of samples of audio data stored in the DMA transfer buffer 44 has reached a predetermined threshold value, even if the remaining audio mixing processing and DMA transfer request processing are executed from that point, the I2C underflow A run error will not occur.
  • the number of samples of audio data stored in the FIFO 131 can be specified by referring to a register of the FIFO 131, for example. Also, the size of the audio data dequeued from the FIFO 131 can be determined by the number of times the FIFO boundary interrupt has occurred. Furthermore, the number of samples of audio data dequeued from the FIFO 131 can be known from the size. For this reason, the number of samples of audio data stored in the FIFO 131 may be calculated from the number of times that the FIFO boundary interrupt has occurred.
  • the standby driver core unit 114 takes over and executes the audio mixing process performed halfway by the driver core unit 127 on the main system side.
  • the spare driver core unit 114 may specify the number of audio data samples mixed by the main driver core unit 127 by referring to the number of audio data samples stored in the DMA transfer buffer 44. it can. As a result, it is possible to specify the audio data to be taken over and started from the audio data stored in the sound cues 41, 42, and 43.
  • the number of samples of audio data stored in the DMA transfer buffer 44 may be specified by the software mixer 128 storing the value in the inter-OS shared memory 40.
  • the audio data stored in the buffer 44 may be identified by counting the number of samples.
  • FIG. 4 is a diagram illustrating the relationship between the number of FIFO boundary interrupts and the threshold value.
  • FIG. 4 shows the case where the audio sampling frequency is about 48000 Hz, the I2S underrun error occurrence time is 1200 ⁇ s, the audio mixing processing time is 700 ⁇ s, and the DMA transfer unit is 1024 samples. It is a figure which shows an example of the threshold value determined to.
  • the value of about 48000 Hz is a frequency used for audio output in an MPEG (Moving / Picture / Experts / Group) moving image.
  • the FIFO 131 has 64 stages and exemplifies a case where 150 ⁇ s is required to transmit 8 stages of data (1 / about 48000 Hz ⁇ 18.75 ⁇ s for transmission of one stage).
  • one sample of audio data is stored in one stage.
  • the size of the mixed audio data is 4 bytes. That is, the case where the FIFO boundary interrupt occurs every time the audio data stored in the FIFO 131 is reduced by 32 (4 bytes ⁇ 8 stages) bytes is illustrated.
  • FIFO boundary interrupt count in FIG. 4 indicates the number of interrupts starting from the reception of the DMA transfer completion interrupt.
  • the “time when the FIFO boundary interrupt occurs” indicates the time from the time of receiving the DMA transfer completion interrupt.
  • the threshold value can be calculated from the number of samples of audio data stored in the FIFO 131 and the audio sampling frequency.
  • the threshold value is “1024”.
  • the driver management unit 115 can refer to, for example, a calculation formula for calculating a threshold from the number of remaining samples in the FIFO 131 and the audio sampling frequency, or a table for specifying the threshold from the number of remaining samples in the FIFO 131 as shown in FIG. By making this, the threshold value can be specified.
  • This calculation formula or table can be referred to by the driver management unit 115 by having the driver management unit 115 or the inter-OS shared memory 40, for example.
  • FIG. 5 is a sequence diagram for explaining audio mixing processing and DMA transfer processing in a state where the main system OS 120 is operating normally.
  • the FIFO boundary interrupt is output to the driver management unit 115 via the common interrupt control unit 16 as shown in FIG. 3, but this point is omitted in FIGS.
  • the common interrupt control unit 16 transmits an interrupt request (IRQ) to a plurality of CPU cores (S101).
  • IRQ interrupt request
  • the driver management unit 115 operating on the standby side OS 110 outputs a FIFO boundary interrupt start request to the I2S device 13 (S102).
  • the I2S device 13 starts outputting the FIFO boundary interrupt.
  • the driver management unit 115 acquires the number of samples of the audio data stored in the DMA transfer buffer 44.
  • the driver management unit 115 determines whether or not the acquired number of samples has reached the threshold (S103).
  • the driver management unit 115 switches the operation to the standby driver core unit 114 because the main driver core 127 operates normally and performs audio mixing processing. Do not do.
  • the driver core unit 127 on the main system side outputs a FIFO boundary interrupt stop request to the I2S device when the audio mixing process ends normally (S104).
  • the I2S device 13 stops the output of the FIFO boundary interrupt.
  • FIG. 6 is a sequence diagram for explaining audio mixing processing and DMA transfer processing in a state where the OS 120 on the main system side becomes inoperable. Note that the processing in S201 and S202 shown in FIG. 6 is the same as the processing in S101 and S101 shown in FIG.
  • the driver management unit 115 When receiving the output of the FIFO boundary interrupt, the driver management unit 115 acquires the number of samples of the audio data stored in the DMA transfer buffer. The driver management unit 115 determines whether or not the acquired number of samples has reached the threshold (S203). Here, in FIG. 6, when the OS 120 on the main system side becomes inoperable, the audio mixing process is not performed, and the number of samples does not reach the threshold value. If the number of samples has not reached the threshold value, the driver management unit 115 switches the operation to the standby driver core unit 114 because the main driver core unit 127 is not operating normally. Specifically, the driver management unit 115 requests the driver core unit 114 on the standby side to start the audio mixing process. As a result, the driver core unit 114 on the standby side starts the audio mixing process.
  • the standby driver core unit 114 outputs a FIFO boundary interrupt stop request to the I2S device after switching the operation (S204).
  • the I2S device 13 stops the output of the FIFO boundary interrupt.
  • the spare driver core unit 114 takes over the audio mixing processing of the audio data from the point where the OS 120 on the main system side becomes inoperable.
  • a parameter front2 is added to each sound cue (ring buffer) in addition to general ring buffer parameters (front, rear).
  • front is a dequeuing parameter used by the driver core unit 127 on the main system side.
  • rear is an enqueue parameter used by the upper application I / F units 126 and 113 of each OS.
  • front2 is a dequeue parameter used by the driver core unit 114 on the standby side.
  • the parameter front2 is used to maintain the consistency of audio data when the main system OS 120 becomes inoperable during the audio mixing process. For example, when the standby OS 110 is waiting, the main driver core unit 127 uses the first full interrupt in the FIFO 131 of the I2S device 13 after the DMA transfer start request as a trigger to transfer the DMA transfer. The front2 is counted for the number of times.
  • the front2 counting method is not limited to this, and a simpler method may be used. For example, a configuration may be adopted in which a DMA transfer completion interrupt thread on the main system side counts front2 at the exit of the thread. That is, the full interrupt in the FIFO 131 of the I2S device 13 may be prohibited and executed.
  • the DMA transfer completion interrupt thread 129 dequeues audio data from the position indicated by using front (portion indicated by hatching in FIG. 7). This dequeue process is counted using the front. That is, every time the audio data is dequeued, the front is counted by the number of samples of the dequeued audio data.
  • the driver core unit 127 on the main system side performs audio mixing processing of a plurality of audio data output from the sound queue using the called software mixer function.
  • the audio data after the audio mixing process stored in the DMA transfer buffer 44 is DMA-transferred from the SDRAM 30 to the FIFO 131 of the I2S device 13.
  • the number of DMA transfers is counted using front2. That is, every time DMA transfer is performed, the front 2 is counted by the number of samples of the audio data transferred by DMA.
  • the front 2 changes following the front after starting the front and the front 2 from the same position.
  • the OS 120 on the main system side becomes inoperable, the dequeuing of the audio data stops halfway and the front count stops.
  • the DMA transfer is not performed when the OS 120) on the main system side becomes inoperable, the count of front2 is stopped and the position of front2 is not updated.
  • the switched driver core unit 114 on the standby system side uses the called software mixer function. Assume that the audio data dequeue is started from the position indicated by the front. In this situation, if the audio data dequeue is started from the position indicated by using the front, the audio data that may be lost is dequeued, and the consistency of the audio data cannot be guaranteed. Therefore, when the OS 120 on the main system side becomes inoperable and the front and front 2 are stopped, the switched driver core unit 114 on the standby system side uses the called software mixer function from the position indicated by the front 2. Start dequeuing audio data. In this way, since dequeuing can be started from the audio data before the main system OS 120 becomes inoperable, it is possible to guarantee the consistency of the audio data before and after switching.
  • the DMA transfer buffer 44 is referred to and the DMA transfer is performed.
  • the front 2 is counted by the number of samples obtained by decrementing the number of audio data samples stored in the buffer 44 by -1. Then, the audio data dequeue is started from the position indicated by the front2.
  • the audio data that may be missing is the audio data that the driver core unit 127 on the main system side has stored after the last audio mixing. It becomes data. Therefore, in this way, in the driver core unit 114 on the standby side, the audio mixing process is taken over and executed from the audio data that the main driver core unit 127 has finally stored and mixed with the audio. Thus, it is possible to guarantee the consistency of audio data before and after switching.
  • the driver core unit 114 on the standby side has a position at least one sample before the position indicated by the amount of audio data stored in the DMA transfer buffer 44 among the positions of the sound queues 41, 42, and 43. Then, the voice mixing process is taken over and executed.
  • the voice mixing processing time is taken over before and after switching from the main side to the standby side by executing the voice mixing processing.
  • the audio mixing processing time can be almost one time. Therefore, even if pattern A is selected when the condition of “voice mixing processing time ⁇ DMA transfer interval ⁇ (voice mixing processing time ⁇ 2)” is satisfied, the standby side does not generate an I2S underrun error. Switching to the system can be performed.
  • the driver core unit 114 on the standby system side which has become the new main system side, is performing the audio mixing process, and the driver core that was on the main system side
  • the base address of the peripheral device (I2S device 13 or DMAC 15) on the shared memory (SDRAM 30) recognized by the OS 120 on the main system side is temporarily stored on the SDRAM 30 by the driver management unit 110 on the standby system side. Change to an invalid address such as the used area. As a result, the OS 120 that was the main system before the switching can be prohibited from accessing the register.
  • audio output from the other OS side can be performed. It is possible to prevent interruption. At that time, even if “audio mixing processing time ⁇ DMA transfer interval ⁇ (audio mixing processing time ⁇ 2)”, the switching from the main system to the standby system is performed by the pattern A that does not reduce the accuracy of the image and sound synchronization. Is possible. Therefore, it is possible to prevent the occurrence of sound interruption while suppressing a decrease in the accuracy of the image / sound synchronization.
  • the determination as to whether or not switching from the main system to the standby system is necessary is based on the number of samples of audio data stored in the inter-OS shared memory. It is possible only by referring. Therefore, the processing speed is not reduced.
  • the period during which the FIFO boundary interrupt is permitted is also a period of the order of several hundreds of DMA transfer cycles every several tens of ms. Therefore, there is very little impact on performance on the standby side.
  • the sound driver is separated into the upper application I / F unit and the driver core unit, and the upper application I / F unit has a sampling rate conversion function. Therefore, even if only the driver core unit on the main system side becomes inoperable, the sampling rate conversion process in the host application I / F unit on the main system can be continued. Therefore, by switching the execution of the audio mixing process to the spare driver core unit, it is possible to continuously reproduce the audio data generated by the OS on the main system side.
  • the present invention is not limited to the above-described embodiment, and can be modified as appropriate without departing from the spirit of the present invention.
  • the MPU 10 may include three or more OSs. In such a case, there are a plurality of OSs on the standby side.
  • Non-transitory computer readable media include various types of tangible storage media (tangible storage medium).
  • Examples of non-transitory computer-readable media include magnetic recording media (eg flexible disks, magnetic tapes, hard disk drives), magneto-optical recording media (eg magneto-optical discs), CD-ROMs (Read Only Memory), CD-Rs, CD-R / W, semiconductor memory (for example, mask ROM, PROM (Programmable ROM), EPROM (Erasable ROM), flash ROM, RAM (random access memory)) are included.
  • the program may also be supplied to the computer by various types of temporary computer-readable media.
  • Examples of transitory computer readable media include electrical signals, optical signals, and electromagnetic waves.
  • the temporary computer-readable medium can supply the program to the computer via a wired communication path such as an electric wire and an optical fiber, or a wireless communication path.
  • Multi-core system 10 50 MPU 11, 12 CPU 13 I2S device 14 I2C device 15 DMA controller 16 Common interrupt control unit 17 HW timer 20 Audio output device 21, 51 ADAC & AMP 22 Speaker 30 SRAM 40 OS shared memory 41, 42, 43, 81, 82 Sound queue 44, 63, 73 DMA transfer buffer 61, 62 Processor core 64 Audio output unit 71, 72, 110, 120 OS 74, 131 FIFO 75 ADAC 111, 121, 122, 123, 711, 721 Application 112, 125 Sound driver 113, 126 Upper application I / F unit 114, 127 Driver core unit 115 Driver management unit 116, 130 Sampling rate conversion function 124 Sound server 128 Software mixer 129 DMA transfer interrupt thread 610, 620 Program 712, 722 Mixed sample counter

Abstract

　画音同期の精度の低下を抑制しつつ、音切れの発生を防止することができるマルチコアシステム、マルチコアシステムの制御方法及びプログラムを提供すること。本発明にかかるマルチコアシステム２は、第１のプロセッサコア６１上で動作し、音声データをミキシングした合成音声データをＤＭＡ転送用バッファ６３に格納する主系プログラム６１０と、第２のプロセッサコア６２上で動作する予備系プログラム６２０と、ＤＭＡ転送用バッファ６３から転送される合成音声データを順次格納し、格納した合成音声データを再生する音声出力部６４を備える。予備系プログラム６２０は、ＤＭＡ転送用バッファ６３に格納される合成音声データの格納量が、音声出力部６４に格納される合成音声データの格納量に応じて定める所定のデータ量に達していない場合、主系プログラム６１０が実行していた合成音声データのミキシング及び格納を引き継いて実行する。

Description

マルチコアシステム、マルチコアシステムの制御方法及びプログラムが格納された非一時的な可読媒体
　本発明は、マルチコアシステム、マルチコアシステムの制御方法及びプログラムが格納された非一時的な可読媒体に関する。
　複数のＣＰＵ(Central Processing Unit)コアを内蔵したマルチコアで構成された組み込み用途向けのプロセッサ(ＭＰＵ：Micro Processing Unit)が開発されている。これらのプロセッサは、周辺デバイスも含めてワンチップ化されている。マルチコアＣＰＵ上において、異なる複数のＯＳ(Operating System)を動作させる技術が知られている。また、ＭＰＵの機能として、単一の割り込み要求(ＩＲＱ：Interrupt ReQuest)を、複数のＣＰＵコアへと通知する手段が知られている。さらに、ＭＰＵは、レジスタ設定に基づいて、どの割り込み要求をどのＣＰＵコアに対して割り当てるかを設定することができる。
　また、例えば、図８に示すように、ＭＰＵ５０内部のＣＰＵからＡＤＡＣ(Audio DAC)５１に対して、Ｉ２Ｓ(Inter-IC Sound)バスを経由して、音声データを転送する技術が知られている。音声データは、例えば、ＰＣＭ(Pulse Code Modulation)音声である。なお、Ｉ２Ｓは、音声データのインターフェイスデバイスを構成する、ＰＨＩＬＩＰＳ(登録商標)社製のシリアル通信フォーマットである。Ｉ２Ｓ規格では、ＰＣＭ音声や圧縮音声(μ－ｌａｗやＡＤＰＣＭなど)を、Ｉ２Ｓバスを経由してＡＤＡＣ５１に出力することができる。また、図８において、Ｉ２Ｃ(Inter-Integrated Circuit)バスは、ＰＨＩＬＩＰＳ(登録商標)社で開発されたデバイス制御用のシリアルバスである。ＡＤＡＣ５１は、音声データをステレオ音声に変換する。ＤＡＣは、Ｄ／Ａコンバータである。ＡＤＡＣ５１から出力されるアナログ音声(ステレオ)が、スピーカーにおいて再生される。
　また、ＦＩＦＯ(First In First Out)バッファを備えるＩ２Ｓデバイスが知られている。このようなＩ２Ｃデバイスは、ＦＩＦＯバッファに格納される音声データをデキューしてＩ２Ｓバスを経由してＡＤＡＣに出力する。そして、ＦＩＦＯバッファからデキューされて減少したデータのサイズが４、８、１６、３２バイト等の境界に達した場合、割り込み(以下、「ＦＩＦＯ境界割り込み」とする)を発生させることが可能なＩ２Ｓデバイスがある。一般的に、この割り込みは、ＰＩＯ(Programmed Input/Output)転送に使用される。
　本願の出願人は、先に出願した特願２００９－１９０１０３において、単一のマルチコアＣＰＵ上で複数のＯＳを動作させる技術を開示している。この技術は、それら複数のＯＳでＩ２Ｃデバイスを共有する場合に、Ｉ２Ｓデバイスを制御するＯＳがカーネルパニック又はフリーズ等によって動作不能となっても、他のＯＳでＩ２Ｃデバイスを制御することができる。これにより、簡易な構成で音切れの発生を防止することができる。
　ここで、図９を参照して、特願２００９－１９０１０３に開示の技術について説明する。図９Ａは、音声データ及び処理の流れを示している。主系側のＯＳは、ＤＭＡ転送完了割り込みをトリガーとして動作し、音声データの音声ミキシング処理及びＤＭＡ転送要求処理を行う。これにより、音声ミキシング処理後の音声データがＦＩＦＯに対してＤＭＡ転送される。
　しかし、主系側のＯＳが動作不能となった場合には、一定の時間内にＤＭＡ転送要求処理が行われなくなる。そのため、Ｉ２Ｓアンダーランエラーが発生する。すなわち、ＤＭＡ転送間隔(ＤＭＡ転送完了割り込みの発生からＩ２Ｓアンダーランエラーが発生するまでの時間を示す)が一定時間を超えた場合には、ＦＩＦＯが空となって音切れが発生する。
　そこで、この技術では、Ｉ２Ｓデバイスに含まれるＦＩＦＯに対して音声データのＤＭＡ転送が行われた後に、複数のＯＳでＤＭＡ(Direct Memory Access)転送割り込みを受信するようにしている。予備系側のＯＳは、ＤＭＡ転送完了割り込みをトリガーとして動作し、ＨＷ(Hard Ware)タイマーを設定する。また、主系側のＯＳは、音声データの音声ミキシング処理及びＤＭＡ転送要求処理を行って、ＨＷタイマーを解除するようにしている。これにより、主系側のＯＳが動作不能となったことを、ＨＷタイマーのタイムアウトによって検出可能としている。そして、ＨＷタイマーがタイムアウトした場合、主系側のＯＳが動作不能となっていることになる。そのため、主系側のＯＳから予備系側のＯＳへと切り替えて、音声ミキシング処理及びＤＭＡ転送要求処理を継続する。これにより、ＦＩＦＯバッファが空になって音切れが発生することを防止している。
　このように、この技術では、主系側のＯＳの動作不能を検出した予備系側のＯＳが、主系側のＯＳに代わって音声ミキシング処理等を継続して行うものである。また、この技術は、Ｉ２Ｓアンダーランエラーが発生しないようにするため、音声ミキシング処理等を行うＤＭＡ転送割り込みスレッドの処理方法を、ＤＭＡ転送完了割り込みの受信に応じて選択することができるようにしている。
　具体的には、音声ミキシング処理時間とＤＭＡ転送間隔(≒Ｉ２Ｓアンダーランエラー発生時間)の大小関係に応じて、パターンＡ、Ｂのいずれかの処理方法を選択するようにしている。なお、音声ミキシング処理時間及びＤＭＡ転送間隔は、実装環境のスペックから算出することができる。実装環境のスペックとは、例えば、Ｉ２ＳデバイスのＦＩＦＯバッファの段数、音声サンプリング周波数、ＤＭＡ転送サイズ及びＣＰＵクロック等である。
　図９Ｂを参照して、パターンＡ、Ｂの選択条件について説明する。図９Ｂは、パターンＡ、Ｂの選択条件における音声ミキシング処理時間とＩ２Ｓアンダーランエラー発生時間の関係を示す。
　選択条件「ＤＭＡ転送間隔＞(音声ミキシング処理時間×２)」を満たす場合には、パターンＡを選択する。パターンＡは、音声ミキシング処理に続いて、ＤＭＡ転送開始要求処理を行う。つまり、この条件に該当するときは、主系のＯＳによる音声ミキシング処理後のＨＷタイマーの解除が行われずに予備系のＯＳに切り替えられ、予備系のＯＳにより音声ミキシング処理を行った後にＤＭＡ転送を開始するものとしても、Ｉ２Ｓアンダーランエラー発生時間経過前にＤＭＡ転送を行うことができるからである。
　選択条件「ＤＭＡ転送間隔≦(音声ミキシング処理時間×２)」を満たす場合には、パターンＢを選択する。パターンＢは、ＤＭＡ転送開始要求処理に続いて、音声ミキシング処理を行う。つまり、この条件に該当するときは、主系のＯＳによる音声ミキシング処理後のＨＷタイマーの解除が行われずに予備系のＯＳに切り替えられ、予備系のＯＳにより音声ミキシング処理を行った後にＤＭＡ転送を開始すると、Ｉ２Ｓアンダーランエラー発生時間経過後にＤＭＡ転送が行われることになってしまうからである。
　また、パターンＢに該当するときは、ＤＭＡ転送開始要求処理を音声ミキシング処理よりも先に行う。そのため、図１０に示すように、音声データを１パケット(ＤＭＡ転送サイズ)分先読みして用意しておく。つまり、音声データがダブルバッファリングされる。しかし、パターンＢでは、音声データを１パケット分先読みする。そのため、画音同期を行う動画プレーヤーで動画を再生する場合、実際に再生中の音声データと、動画プレーヤーが再生中と認識する音声データが１パケット分ずれてしまい、画音同期の精度が低下してしまうという問題があった。
　ここで、図１１を参照して、この問題について具体的に説明する。図１１は、主系側のＯＳがＯＳ７２であり、予備系側のＯＳがＯＳ７１の場合について例示している。ＯＳ７１は、ミキシング済みカウンタ７１２を有する。ＯＳ７２は、ミキシング済みカウンタ７２２を有する。まず、主系側のＯＳ７２上で動作するアプリケーションプログラム(図においては、略して「ＡＰＰ」として示す)７２１は、サウンドキュー８２に音声データをエンキューする。アプリケーションプログラム７２１は、例えば、サンプリング周波数が４８０００Ｈｚで、１６ｂｉｔステレオの音声を含む動画を再生する。また、アプリケーションプログラム７２１は、例えば、４０９６ｂｙｔｅ単位、かつ、(１０２４／４８０００)秒間隔で音声データを送出する。
　予備系側のＯＳ７１上で動作するアプリケーションプログラム(図においては、略して「ＡＰＰ」として示す)７１１は、サウンドキュー８１に音声データをエンキューする。そして、主系側のＯＳ７２上で動作するソフトウェアミキサ７２３は、サウンドキュー８１、８２からデキューした音声データをミキシングする。ソフトウェアミキサ７２３は、ミキシング後の音声データをＤＭＡ転送用の音声データとしてＤＭＡ転送用バッファ７３に格納する。ＤＭＡ転送用バッファ７３に格納された音声データは、Ｉ２ＳデバイスのＦＩＦＯ７４に転送される。そして、ＦＩＦＯ７４からデキューされた音声データはＡＤＡＣ７５によって再生される。
　このように、ソフトウェアミキサ７２３は、複数のアプリケーションプログラムから出力された異なるサンプリング周波数及び量子化ビット数の音声データを単一の音声データに変換する。また、ソフトウェアミキサ７２３は、音声データをミキシングする毎に、ミキシング済みサンプル数カウンタ７２２のカウンタ値を、ミキシングして生成した音声データのサンプル数分、カウントアップする。
　主系側のＯＳ７２上で動作するアプリケーションプログラム７２１は、ミキシング済みサンプル数カウンタ７２２のカウンタ値を参照することで、音声データの送出間隔の計算及び画音同期を行う。つまり、アプリケーションプログラム７２１は、画音同期を行って動画を再生する場合、ミキシング済みの音声データのサンプル数に対応する画像を再生する。したがって、パターンＢのように、音声データを１パケット分先読みしてミキシングを行う処理方法では、再生される画像が実際に出力されている音声と大きくずれてしまい、画音同期の精度が低下してしまう。
　本発明の目的は、上述した課題を解決するために、画音同期の精度の低下を抑制しつつ、音切れの発生を防止することができるマルチコアシステム、マルチコアシステムの制御方法及びプログラムを提供することである。
　本発明の第１の態様にかかるマルチコアシステムは、第１のプロセッサコア上で動作し、第１及び第２の音声データをミキシングして、当該ミキシングした合成音声データをＤＭＡ転送用バッファに格納する主系プログラムと、第２のプロセッサコア上で動作し、前記主系プログラムの予備系として動作する予備系プログラムと、前記ＤＭＡ転送用バッファから転送される合成音声データを順次格納し、当該格納した合成音声データを再生する音声出力部と、を備え、前記予備系プログラムは、前記ＤＭＡ転送用バッファに格納される合成音声データの格納量が、前記音声出力部に格納される合成音声データの格納量に応じて定める所定のデータ量に達していない場合、前記主系プログラムが実行していた合成音声データのミキシング及び格納を引き継いて実行することを特徴とする。
　本発明の第２の態様にかかるマルチコアシステムの制御方法は、第１のプロセッサコア上で動作し、第１及び第２の音声データをミキシングして、当該ミキシングした合成音声データをＤＭＡ転送用バッファに格納する主系プログラムと、第２のプロセッサコア上で動作し、前記主系プログラムの予備系として動作する予備系プログラムと、前記ＤＭＡ転送用バッファから転送される合成音声データを順次格納し、当該格納した合成音声データを再生する音声出力部と、を備えたマルチコアシステムの制御方法であって、前記ＤＭＡ転送用バッファに格納される合成音声データの格納量が、前記音声出力部に格納される合成音声データの格納量に応じて定める所定のデータ量に達しているか否かを判定するステップと、前記所定のデータ量に達していると判定した場合に、前記予備系プログラムが、前記主系プログラムが実行していた合成音声データのミキシング及び格納を引き継いて実行するステップと、を備えることを特徴とする。
　本発明の第３の態様にかかるプログラムは、転送されてくる合成音声データを順次格納し、当該格納した合成音声データを再生する音声出力部に対して転送される合成音声データを格納するＤＭＡ転送用バッファに、第１及び第２の音声データをミキシングした合成音声データを格納する主系プログラムとは異なるプロセッサコア上で、当該主系のプログラムの予備系として動作する予備系のプログラムであって、前記ＤＭＡ転送用バッファに格納される合成音声データの格納量が、前記音声出力部に格納される合成音声データの格納量に応じて定める所定のデータ量に達しているか否かを判定するステップと、前記所定のデータ量に達していると判定した場合に、前記予備系プログラムが、前記主系プログラムが実行していた合成音声データのミキシング及び格納を引き継いて実行するステップと、を前記プロセッサコアに実行させることを特徴とする。
　上述した本発明の各態様により、画音同期の精度の低下を抑制しつつ、音切れの発生を防止することができるマルチコアシステム、マルチコアシステムの制御方法及びプログラムを提供することができる。
本発明の実施の形態にかかるマルチコアシステムのハードウェア構成の概要を示すブロック図である。 本発明の実施の形態にかかるマルチコアシステムのハードウェア構成を示すブロック図である。 本発明の実施の形態にかかるマルチコアシステムの機能構成を示すブロック図である。 本発明の実施の形態にかかるＦＩＦＯ境界割り込み回数と閾値との関係を示す図である。 本発明の実施の形態にかかる主系側のＯＳが正常に動作している状態での、音声ミキシング処理及びＤＭＡ転送処理を説明するシーケンス図である。 本発明の実施の形態にかかる主系側のＯＳが動作不能となった状態での、音声ミキシング処理及びＤＭＡ転送処理を説明するシーケンス図である。 本発明の実施の形態にかかるサウンドキューに関するパラメータを説明するための図である。 本発明に関連する技術を説明するための図である。 本発明に関連する技術の音声データ及び処理の流れを示す図である。 本発明に関連する技術の音声データ及び処理の流れを示す図である。 本発明に関連する技術の音声ミキシング処理及びＤＭＡ転送開始要求処理の処理方法を説明するための図である。 本発明に関連する技術の画音同期の精度が低下してしまうという問題を説明するための図である。
　まず、図１を参照して、本発明の実施の形態にかかるマルチコアシステムの概要について説明する。図１は、本実施の形態にかかるマルチコアシステムのハードウェア構成の概要を示すブロック図である。
　マルチコアシステム２は、プロセッサコア６１、６２と、ＤＭＡ転送用バッファ６３と、音声出力部６４と、を備える。
　プロセッサコア６１は、主系として動作するプログラム６１０を動作させる。
　プロセッサコア６２は、予備系として動作するプログラム６２０を動作させる。
　ＤＭＡ転送用バッファ６３は、プログラム６１、６２がミキシングした合成音声データを格納する。
　音声出力部６４は、ＤＭＡ転送用バッファ６３から転送される合成音声データを順次格納し、格納した合成音声データを再生する。
　プログラム６１０は、第１及び第２の音声データをミキシングして、ミキシングした合成音声データをＤＭＡ転送用バッファ６３に格納する。プログラム６１は、主系として動作するプログラムである。
　プログラム６２０は、主系プログラムの予備系として動作する。
　続いて、本発明の実施の形態にかかるマルチコアシステムの処理の概要について説明する。
　主系のプログラム６１０は、第１及び第２の音声データをミキシングして、ミキシングした合成音声データをＤＭＡ転送用バッファ６３に格納する。そして、ＤＭＡ転送用バッファ６３に格納された合成音声データが一定のデータ量に達したときに、ＤＭＡ転送用バッファ６３に格納された合成音声データが音声出力部６４に転送される。音声出力部６４は、ＤＭＡ転送用バッファ６３から転送された合成音声データを順次格納し、当該格納した合成音声データを再生する。
　予備系のプログラム６２０は、ＤＭＡ転送用バッファ６３に格納される合成音声データの格納量が、音声出力部６４に格納される合成音声データの格納量に応じて定める所定のデータ量に達しているか否かを判定する。そして、所定のデータ量に達していない場合、主系プログラムが６１０実行していた合成音声データのミキシング及び格納を引き継いて実行する。
　続いて、図２及び図３を参照して、本発明の実施の形態にかかるマルチコアシステムの構成について説明する。図２は、本実施の形態にかかるマルチコアシステムのハードウェア構成を示すブロック図である。
　図２に示すように、マルチコアシステム１は、組み込み用のＭＰＵ１０と、音声出力装置２０と、ＳＤＲＡＭ(Synchronous Dynamic Random Access Memory)３０と、を備えている。ＳＤＲＡＭは、外部共有メモリとして機能する。
　ＭＰＵ１０は、マルチコアＣＰＵと、周辺デバイス(Ｉ２Ｓデバイス１３、Ｉ２Ｃデバイス１４、ＤＭＡＣ１５)とがワンチップ化されたＩＣ(Integrated Circuit)である。ＣＰＵ１１、１２は、それぞれ１つ又は複数のＣＰＵコアを含む。例えば、４つのＣＰＵコアを有するマルチコアＣＰＵのうち、ＣＰＵ１１はＣＰＵコア１つを含み、ＣＰＵ１２はＣＰＵコア３つを含む。また、ＣＰＵ１１、１２は、複数のマルチコアＣＰＵから構成されるようにしてもよい。ＣＰＵコアは、プロセッサコア６１、６２に相当する。
　ＭＰＵ１０は、マルチコアＣＰＵ上において、複数のＯＳを動作させる。ＯＳ１１０がＣＰＵ１１上において動作する。ＯＳ１２０がＣＰＵ１２上において動作する。なお、ＯＳ１１０とＯＳ１２０は異なる種類のＯＳである。例えば、ＯＳ１１０をμＩＴＲＯＮ等のリアルタイムＯＳとし、ＯＳ１２０は高機能組み込みＯＳとする組み合わせが考えられる。高機能組み込みＯＳとは、例えば、組み込みＬｉｎｕｘ(登録商標)やＷｉｎｄｏｗｓ ＣＥ(登録商標)等である。
　ＯＳ１１０上において、アプリケーションプログラム１１１(図においては、略して「ＡＰＰ」として示す)、及びデバイスドライバであるサウンドドライバ１１２が動作する。アプリケーションプログラム１１１から出力された音声データが、サウンドドライバ１１２へと入力される。また、ＯＳ１２０上において、アプリケーションプログラム１２１、１２２、１２３(図においては、略して「ＡＰＰ」としてそれぞれ示す)、サウンドサーバ１２４、及びデバイスドライバであるサウンドドライバ１２５が動作する。アプリケーションプログラム１２１及びアプリケーションプログラム１２２から出力された音声データは、サウンドサーバ１２４へと入力される。サウンドサーバ１２４から出力される音声データと、アプリケーションプログラム１２３から出力された音声データとが、サウンドドライバ１２５へと入力される。
　Ｉ２Ｓデバイス１３は、Ｉ２Ｓバス(Ｉ２Ｓ ｂｕｓ)を経由して音声データをＡＤＡＣ＆ＡＭＰ２１へと送信する。Ｉ２Ｓデバイス１３は、１系統のデバイスである。Ｉ２Ｓデバイス１３はＦＩＦＯ１３１を備える。Ｉ２Ｓデバイス１３は、ＦＩＦＯ１３１に音声データを格納する。ここでは、Ｉ２Ｓデバイス１３は、音声データとして、ステレオＰＣＭを扱う。
　Ｉ２Ｃデバイス１４は、デバイス制御用のシリアルバスである。Ｉ２Ｃデバイス１４は、ＡＤＡＣが備えるレジスタへの読み書きを行うために使用される。
　ＤＭＡＣ(ＤＭＡ Ｃｏｎｔｏｒｏｌｌｅｒ)１５は、ＭＰＵ１０の外部に接続されたＳＤＡＲＭ３０と、他のデバイス間のＤＭＡ転送を制御する。ここでは、ＳＤＲＡＭ３０上のＯＳ間共有メモリ４０から、Ｉ２Ｓデバイス１３のＦＩＦＯ１３１への音声データの転送を、ＤＭＡＣ１５の１チャンネルを用いて行う。
　なお、本実施の形態では、通常、ＯＳ１２０側のサウンドドライバ１２５が、音声ミキシング処理及び周辺デバイス(Ｉ２Ｓデバイス１３、Ｉ２Ｃデバイス１４、ＤＭＡＣ１５)の制御を行うものとして説明する。
　音声出力装置２０は、ＡＤＡＣ＆ＡＭＰ２１と、スピーカー２２とを備えている。ＡＤＡＣ＆ＡＭＰ２１は、音声出力装置２０の外部インタフェースを構成する。ＡＤＡＣ＆ＡＭＰ２１は、Ｉ２Ｓバスを経由して送信される音声データをアナログ信号に変換・増幅する。ＡＤＡＣ＆ＡＭＰ２１は、アナログ信号をスピーカー２２を用いて再生する。Ｉ２Ｓデバイス１３及び音声出力装置２０は、音声出力部６４に相当する。
　ＳＤＲＡＭ３０は、ＭＰＵ１０の外部にバスを介して接続される、揮発性のメモリ(ＲＡＭ)である。ＳＤＲＡＭ３０には、ＯＳ間共有メモリ４０として、ＭＰＵ１０のＯＳが共有するメモリ空間が確保される。
　ＯＳ間共有メモリ４０内には、サウンドキュー(サウンドキュー４１、サウンドキュー４２、サウンドキュー４３)及びＤＭＡ転送用バッファ４４が設定される。サウンドキューは、アプリケーションプログラムが出力した音声データを格納するリングバッファである。サウンドキューとして、音声データを出力するアプリケーションプログラムの数に相当する数のキューが作成される。ここでは、ＯＳ１１０のアプリケーションプログラム１１１と、ＯＳ１２０のサウンドサーバ１２４と、ＯＳ１２０のアプリケーションプログラム１２３とに相当する、３個のサウンドキュー(サウンドキュー４１、サウンドキュー４２、サウンドキュー４３)が作成される。サウンドキュー(サウンドキュー４１、サウンドキュー４２、サウンドキュー４３)の音声データが音声ミキシング処理された後に、ＤＭＡ転送用バッファ４４に格納される。なお、サウンドキューは、リングバッファ以外のキューイング手段を用いて構成するものとしてもよい。
　図３は、本実施の形態にかかるマルチコアシステムの機能構成を示すブロック図である。図３では、図２において示したサウンドドライバ１１２を、上位アプリＩ／Ｆ部１１３とドライバコア部１１４に分割して示している。また、サウンドドライバ１２５を、上位アプリＩ／Ｆ部１２６とドライバコア部１２７に分割して示している。上位アプリＩ／Ｆ部１１３は、サンプリングレート変換機能１１６を有する。上位アプリＩ／Ｆ部１２６は、サンプリングレート変換機能１３０を有する。
　上位アプリＩ／Ｆ部１１３は、アプリケーションプログラム１１１から出力された音声データをＯＳ間共有メモリ４０内のサウンドキュー４１に格納する。このときに、上位アプリＩ／Ｆ部１１３のサンプリングレート変換機能１１６は、アプリケーションプログラム１１１から受け取った音声データに対して、サンプリングレートの変換や量子化ビット数の変換を必要に応じて行う。上位アプリＩ／Ｆ部１１３は、変換後の音声データを、ＯＳ間共有メモリ４０内のサウンドキュー４１へと格納する。
　上位アプリＩ／Ｆ部１２６は、サウンドサーバ１２４とアプリケーションプログラム１２３とから出力された音声データをＯＳ間共有メモリ４０内のサウンドキュー４２、４３に格納する。このときに、上位アプリＩ／Ｆ部１２６のサンプリングレート変換機能１３０は、サウンドサーバ１２４とアプリケーションプログラム１２３とから受け取った音声データに対して、サンプリングレートの変換や量子化ビット数の変換を必要に応じて行う。上位アプリＩ／Ｆ部１２６は、変換後の音声データを、ＯＳ間共有メモリ４０内のサウンドキュー４２、４３へと格納する。サンプリングレート変換機能１１６、１３０は、例えば、４８ｋＨｚ ２３ｂｉｔの音声を、４４．１ｋＨｚ １６ｂｉｔの音声へと変換する。
　ドライバコア部１１４、１２７は、ＯＳ間共有メモリ４０の各サウンドキューに格納された音声データをミキシングする。ドライバコア部１１４、１２７は、音声ミキシング処理後の音声データを、ＤＭＡ転送を用いてＩ２Ｓデバイス１３のＦＩＦＯ１３１へと転送する。なお、本実施の形態では、サウンドドライバ１１２、１２５の一部であって、音声ミキシング処理及びＩ２Ｓデバイス１３、Ｉ２Ｃデバイス１４の制御を行う機能部分を、ドライバコア部１１４、１２５として定義する。また、音声ミキシング処理とは、各ＯＳ上で動作する複数のアプリケーションプログラムから出力された音声データをミキシングして、単一の音声データとしてＤＭＡ転送用の領域(ＤＭＡ転送用バッファ４４)にコピーする処理を指す。
　本実施の形態では、システム動作時に、複数のＯＳのうち、１つのＯＳ(主系)のドライバコア部のみが動作する。その他のＯＳ(予備系)のドライバコア部は、通常は待機状態となっている。予備系は、主系側のＯＳがカーネルパニックやフリーズ等した場合にのみ動作する。なお、主系とは、正常時に動作するドライバコア部を有するシステムを指す。予備系とは、主系側の動作不能となった時に動作するドライバコア部を有するシステムを指す。ここで、主系及び予備系とは、あくまでもサウンド再生機能(サウンドドライバの一部機能)についての主系及び予備系であり、主系ＯＳ及び予備系ＯＳのことではない。すなわち、予備系側のＯＳとは、サウンド再生機能に関する予備系としての機能を備えているＯＳのことを指す。
　ソフトウェアミキサ１２８は、ドライバコア部１２７が呼び出す関数である。ソフトウェアミキサ１２８は、各サウンドキューに格納された音声データをミキシングする。ソフトウェアミキサ１２８は、ミキシング後の音声データをＤＭＡ転送用バッファ４４に格納する。
　共通割り込み制御部１６は、各ＣＰＵコアに対して、割り込み要求(ＩＲＱ)の割り振りを行う。共通割り込み制御部１６は、基本的には、ＭＰＵ１０内にハードウェアの機能として備えらえる。なお、共通割り込み制御部１６がＭＰＵ１０内にハードウェアの機能として搭載されていない場合には、ソフトウエアの機能として実装することも可能である。
　共通割込み制御部１６に入力される割り込み要求は、音声データのＤＭＡ転送が完了した場合に、ＤＭＡＣ１５が発行するＤＭＡ転送完了割り込みと、Ｉ２Ｓデバイス１３が発行するＦＩＦＯ境界割り込みである。ＤＭＡ転送完了割り込みの発生から一定の時間内にＤＭＡ転送要求が無い場合には、Ｉ２Ｓデバイス１３のＦＩＦＯ１３１のバッファが空となり、Ｉ２Ｓアンダーランエラーが発生する。
　ドライバ管理部１１５は、予備系側のＯＳの割り込みハンドラが呼び出す関数群である。ドライバ管理部１１５は、ＨＷタイマー１７の設定、ＦＩＦＯ境界割り込みのＯＮ／ＯＦＦの設定や、主系のドライバコア部を用いた動作を予備系のドライバコア部を用いた動作へと切り替える切り替処理を行う。なお、ここでは、ＨＷタイマー１７は、ＭＰＵ１０が備えるハードウェアタイマーを指す。
　続いて、本発明の実施の形態にかかるマルチコアシステムの動作を概略的に説明する。
　ＳＤＲＡＭ３０からＦＩＦＯ１３１に対してＤＭＡ転送が行われた後に、複数のＯＳ１１０、１２０がＤＭＡ転送完了割り込みを受信する。主系側のＯＳ１２０が正常に動作している場合には、受信したＤＭＡ転送完了割り込みが、ＤＭＡ転送完了割り込みスレッド１２９に到達する。そして、ＤＭＡ転送完了割り込みスレッド１２９は、音声データのＤＭＡ転送完了割り込みをトリガーとして動作し、音声データの音声ミキシング処理及びＤＭＡ転送要求処理を行う。そして、ＤＭＡ転送用バッファ４４に格納された音声ミキシング処理後の音声データが、ＳＤＲＡＭ３０からＦＩＦＯ１３１に対してＤＭＡ転送される。
　なお、音声ミキシング処理及びＤＭＡ転送開始要求処理の処理順序に関して、主系側のＯＳ１２０における音声ミキシング処理時間とＩ２Ｓアンダーランエラーの関係に基づいて、パターンＡ又はパターンＢのいずれかのパターンを選択する。
　選択条件「ＤＭＡ転送間隔＞(音声ミキシング処理時間×２)」を満たす場合には、パターンＡを選択する。そして、パターンＡでは、音声ミキシング処理に続いて、ＤＭＡ転送開始要求処理を行うという順序で処理が行われる。すなわち、この場合には、ＤＭＡ転送開始要求処理に先立ち、音声ミキシング処理を行う。
　選択条件「ＤＭＡ転送間隔≦(音声ミキシング処理時間×２)」を満たす場合には、パターンＢを選択する。そして、パターンＢでは、ＤＭＡ転送開始要求処理に続いて、音声ミキシング処理を行うという順序で処理が行われる。すなわち、この場合には、音声ミキシング処理に先立ち、ＤＭＡ転送開始要求処理を行う。また、ＤＭＡ転送を行う音声データの１パケット(＝ＤＭＡ転送サイズ)分の先読みを行うために、音声データのダブルバッファリング処理が必要となる。
　また、本実施の形態では、選択条件「音声ミキシング処理時間＜ＤＭＡ転送間隔≦(音声ミキシング処理時間×２)」を満たす場合には、選択条件「ＤＭＡ転送間隔≦(音声ミキシング処理時間×２)」を満たすときであっても、パターンＡを選択する。つまり、パターンＢの選択条件は、正確には、「音声ミキシング処理時間≧ＤＭＡ転送間隔」かつ「ＤＭＡ転送間隔≦(音声ミキシング処理時間×２)」となる。
　続いて、本発明の実施の形態にかかるマルチコアシステムの主系側のＯＳ１２０の監視機能について説明する。まず、選択条件「ＤＭＡ転送間隔＞(音声ミキシング処理時間×２)」を満たすときにパターンＡを選択した場合と、パターンＢを選択した場合について説明する。
　この場合に予備系側のＯＳ１１０がＤＭＡ転送完了割込みを受信したときは、予備系側のＯＳ１１０が備える割り込みハンドラによって動作するドライバ管理部１１５が、ＨＷタイマー１７を設定する。そして、ＤＭＡ転送完了割り込みが、主系側のＯＳ１２０のＤＭＡ転送完了割り込みスレッド１２９に到達した場合には、ＤＭＡ転送完了割り込みスレッド１２９が、設定したＨＷタイマー１７を解除する。これにより、ＤＭＡ転送完了割り込みが、主系側のＯＳ１２０のＤＭＡ転送完了割り込みスレッド１２９にまで到達しなかった場合には、設定したＨＷタイマー１７は解除されずにタイムアウトする。したがって、ＨＷタイマー１７のタイムアウトの有無に基づいて、主系側のＯＳ１２０の動作不能を監視することが可能となる。
　次に、選択条件「音声ミキシング処理時間＜ＤＭＡ転送間隔≦(音声ミキシング処理時間×２)」を満たすときにパターンＡを選択した場合について説明する。
　この場合に予備系側のＯＳ１１０がＤＭＡ転送完了割込みを受信したときは、予備系側のＯＳ１１０が備える割り込みハンドラによって動作するドライバ管理部１１５が、Ｉ２Ｓデバイス１３のＦＩＦＯ境界割り込みの受信を許可する。また、予備系側のＯＳ１１０がＦＩＦＯ境界割り込みを受信した場合、ドライバ管理部１１５は、ＤＭＡ転送用バッファ４４に格納されている音声データのサンプル数が所定の閾値に達しているか否かを判定する。判定の結果、音声データのサンプル数が、ＦＩＦＯ１３１に格納されている音声データのサンプル数から算出される所定の閾値に達していない場合、ドライバ管理部１１５は、主系のドライバコア部１２７を用いた動作を予備系のドライバコア部１１４を用いた動作へと切り替える切り替処理を行う。
　ここで、所定の閾値とは、ＦＩＦＯ１３１に格納されている残りの音声データが全てデキューされるまでに、残りの音声ミキシング処理及びＤＭＡ転送要求処理の実行を完了させることが可能なサンプル数の音声データがＤＭＡ転送用バッファ４４に格納されているかどうかを判定するための基準値である。つまり、ＤＭＡ転送用バッファ４４に格納されている音声データのサンプル数が、所定の閾値に達している場合は、その時点から残りの音声ミキシング処理及びＤＭＡ転送要求処理を実行しても、Ｉ２Ｃアンダーランエラーが発生しないことになる。
　ＦＩＦＯ１３１に格納される音声データのサンプル数は、例えば、ＦＩＦＯ１３１のレジスタを参照することによって特定することができる。また、ＦＩＦＯ境界割り込みが発生した回数によって、ＦＩＦＯ１３１からデキューされた音声データのサイズが分かる。さらに、そのサイズによってＦＩＦＯ１３１からデキューされた音声データのサンプル数が分かる。そのため、ＦＩＦＯ境界割り込みが発生した回数から、ＦＩＦＯ１３１に格納されている音声データのサンプル数を算出するようにしてもよい。
　ここで、予備系のドライバコア部１１４に動作を切り替えた場合、予備系のドライバコア部１１４は、主系側のドライバコア部１２７が途中まで行った音声ミキシング処理を引き継いで実行する。予備系のドライバコア部１１４は、ＤＭＡ転送用バッファ４４に格納される音声データのサンプル数を参照することで、主系側のドライバコア部１２７がミキシングした音声データのサンプル数を特定することができる。これにより、サウンドキュー４１、４２、４３に格納される音声データのうちから、引き継いでミキシングを開始する音声データを特定することができる。なお、ＤＭＡ転送用バッファ４４に格納される音声データのサンプル数は、ソフトウェアミキサ１２８がＯＳ間共有メモリ４０にその値を格納しておくことによって特定することができるようにしてもよく、ＤＭＡ転送用バッファ４４に格納されている音声データのサンプル数を数えることによって特定することができるようにしてもよい。
　続いて、図４を参照して、閾値の一例について説明する。図４は、ＦＩＦＯ境界割り込み回数と閾値との関係を示す図である。
　図４は、マルチコアシステム１の動作スペックとして、音声サンプリング周波数が約４８０００Ｈｚであり、Ｉ２Ｓアンダーランエラー発生時間が１２００μｓであり、音声ミキシング処理時間が７００μｓであり、ＤＭＡ転送単位が１０２４サンプルである場合に決定される閾値の一例を示す図である。約４８０００Ｈｚという値は、ＭＰＥＧ(Moving Picture Experts Group)動画における音声出力等で使用される周波数である。ＦＩＦＯ１３１は、段数が６４段であり、８段分のデータを送出するのに１５０μｓ(１段分の送出に１／約４８０００Ｈｚ≒１８．７５μｓ)が必要な場合について例示している。ここで、１段に１サンプルの音声データが格納されている。また、ミキシングされた音声データのサイズが４ｂｙｔｅであるものとする。つまり、ＦＩＦＯ１３１に格納される音声データが３２(４ｂｙｔｅ×８段)バイト減少する毎に、ＦＩＦＯ境界割り込みが発生する場合について例示している。
　図４の「ＦＩＦＯ境界割り込み回数」は、ＤＭＡ転送完了割り込みの受信時を起点とした割り込みの回数を示す。また、「ＦＩＦＯ境界割り込みが発生する時間」は、ＤＭＡ転送完了割り込みの受信時を起点とした時間を示す。なお、閾値は、ＦＩＦＯ１３１に格納される音声データのサンプル数と、音声サンプリング周波数から算出可能である。
　例えば、７回目のＦＩＦＯ境界割り込みが発生した場合、ＦＩＦＯ１３１の残りサンプル数は８サンプルである。したがって、８サンプルが送出される１５０μｓが経過するとＩ２Ｓアンダーランエラーになると算出することができる。ここで、１５０μｓの余裕をもってＤＭＡ転送単位のサンプル数の音声データのミキシングが完了していることを期待値とした場合、７回目のＦＩＦＯ境界割り込みが発生した時点で、ＤＭＡ転送用バッファ４４に１０２４サンプルの音声データが格納されている必要がある。この場合、図４に示すように、閾値を「１０２４」とする。
　ドライバ管理部１１５は、例えば、ＦＩＦＯ１３１の残りサンプル数や音声サンプリング周波数から閾値を算出する計算式や、図４に示すようにＦＩＦＯ１３１の残りサンプル数から閾値を特定するテーブルを参照することができるようにすることで閾値を特定可能とする。この計算式又はテーブルは、例えば、ドライバ管理部１１５や、ＯＳ間共有メモリ４０が有することで、ドライバ管理部１１５が参照可能とする。
　続いて、図５及び図６を参照して、主系側のＯＳ１２０の動作不能を検出した場合における、ドライバコア部の切り替え動作について説明する。まず、図５を参照して、主系側のＯＳ１２０が正常に動作している場合において、ＤＭＡ転送完了割り込みを受信した後の処理について説明する。図５は、主系側のＯＳ１２０が正常に動作している状態での、音声ミキシング処理及びＤＭＡ転送処理を説明するシーケンス図である。なお、ＦＩＦＯ境界割り込みは、図３に示すように共通割り込み制御部１６を経由してドライバ管理部１１５に出力されるが、図５及び図６ではその点について省略して記載している。
　まず、ＤＭＡ転送完了割り込みをＭＰＵ１０が受信した場合には、共通割り込み制御部１６は、複数のＣＰＵコアに対して、割り込み要求(ＩＲＱ)を送信する(Ｓ１０１)。
　次に、予備系側のＯＳ１１０上において動作するドライバ管理部１１５は、共通割込み制御部１６から割り込み要求(ＩＲＱ)を受信すると、ＦＩＦＯ境界割り込み開始要求をＩ２Ｓデバイス１３に出力する(Ｓ１０２）。Ｉ２Ｓデバイス１３は、ＦＩＦＯ境界割り込み開始要求の出力を受けると、ＦＩＦＯ境界割り込みの出力を開始する。
　次に、ドライバ管理部１１５は、ＦＩＦＯ境界割り込みの出力を受けると、ＤＭＡ転送用バッファ４４に格納される音声データのサンプル数を取得する。ドライバ管理部１１５は、取得したサンプル数が閾値に達しているか否かを判定する(Ｓ１０３)。ドライバ管理部１１５は、サンプル数が閾値に達している場合、主系側のドライバコア１２７が正常に動作して音声ミキシング処理を行っているため、予備系のドライバコア部１１４への動作の切り替えは行わない。
　次に、主系側のドライバコア部１２７は、音声ミキシング処理が正常に終了した場合、ＦＩＦＯ境界割り込み停止要求をＩ２Ｓデバイスに出力する(Ｓ１０４)。Ｉ２Ｓデバイス１３は、ＦＩＦＯ境界割り込み停止要求の出力を受けると、ＦＩＦＯ境界割り込みの出力を停止する。
　次に、図６を参照して、主系側のＯＳ１２０が動作不能となった場合に、予備系側のＯＳを用いて、音声ミキシング処理及びＤＭＡ転送処理を継続して行う処理について説明する。図６は、主系側のＯＳ１２０が動作不能となった状態での、音声ミキシング処理及びＤＭＡ転送処理を説明するシーケンス図である。なお、図６において示すＳ２０１及びＳ２０２での処理は図５で示したＳ１０１及びＳ１０１での処理と同一であるため、ここではその説明を省略する。
　ドライバ管理部１１５は、ＦＩＦＯ境界割り込みの出力を受けると、ＤＭＡ転送バッファに格納される音声データのサンプル数を取得する。ドライバ管理部１１５は、取得したサンプル数が閾値に達しているか否かを判定する(Ｓ２０３)。ここで、図６において、主系側のＯＳ１２０が動作不能となった場合には、音声ミキシング処理が行われなくなり、サンプル数が閾値に達しなくなる。ドライバ管理部１１５は、サンプル数が閾値に達していない場合、主系側のドライバコア部１２７が正常に動作していないため、予備系のドライバコア部１１４への動作の切り替えを行う。具体的には、ドライバ管理部１１５は、予備系側のドライバコア部１１４に対して音声ミキシング処理の開始を要求する。これにより、予備系側のドライバコア部１１４が、音声ミキシング処理を開始する。
　予備系のドライバコア部１１４は、動作の切り替え後、Ｉ２Ｓデバイスに対してＦＩＦＯ境界割り込み停止要求を出力する(Ｓ２０４)。Ｉ２Ｓデバイス１３は、ＦＩＦＯ境界割り込み停止要求の出力を受けると、ＦＩＦＯ境界割り込みの出力を停止する。そして、予備系のドライバコア部１１４は、主系側のＯＳ１２０が動作不能となったところから、音声データの音声ミキシング処理を引き継いで行う。
　ここで、図７を参照して、主系側のＯＳ１２０が動作不能となったところから、音声データの音声ミキシング処理を引き継いで行う処理について具体的に説明する。
　図７に示すように、本実施の形態では、各サウンドキュー(リングバッファ)に対して、一般的なリングバッファのパラメータ(ｆｒｏｎｔ、ｒｅａｒ)に加えて、パラメータｆｒｏｎｔ２を追加する。ここで、ｆｒｏｎｔは、主系側のドライバコア部１２７が使用する、デキュー用のパラメータである。また、ｒｅａｒは、各ＯＳの上位アプリＩ／Ｆ部１２６、１１３が使用する、エンキュー用のパラメータである。また、ｆｒｏｎｔ２は、予備系側のドライバコア部１１４が使用する、デキュー用のパラメータである。
　パラメータｆｒｏｎｔ２は、音声ミキシング処理中に主系側のＯＳ１２０が動作不能となってしまった場合に、音声データの整合性を保つために使用する。例えば、予備系側のＯＳ１１０が待機している時に、主系側のドライバコア部１２７が、ＤＭＡ転送開始要求後に、Ｉ２Ｓデバイス１３のＦＩＦＯ１３１における最初のフル割り込みの発生をトリガーとして、ＤＭＡ転送の転送回数分、ｆｒｏｎｔ２をカウントする。なお、ｆｒｏｎｔ２のカウント方法としてはこれに限定されず、より簡易的な方法を用いてもよい。例えば、主系側のＤＭＡ転送完了割り込みスレッドが、スレッドの出口においてｆｒｏｎｔ２をカウントする構成としてもよい。つまり、Ｉ２Ｓデバイス１３のＦＩＦＯ１３１におけるフル割り込みを禁止して実施してもよい。
　主系側のＯＳ１２０が正常に動作している場合には、ＤＭＡ転送完了割り込みスレッド１２９は、ｆｒｏｎｔを用いて示す位置からの音声データ(図７において斜線を用いて示す部分)をデキューする。このデキュー処理は、ｆｒｏｎｔを用いてカウントされる。つまり、音声データをデキューする毎に、デキューした音声データのサンプル数分、ｆｒｏｎｔをカウントしていく。次いで、主系側のドライバコア部１２７が、呼び出したソフトウェアミキサ関数を用いて、サウンドキューから出力された複数の音声データの音声ミキシング処理を行う。次いで、ＤＭＡ転送用バッファ４４に格納された音声ミキシング処理後の音声データが、ＳＤＲＡＭ３０からＩ２Ｓデバイス１３のＦＩＦＯ１３１へとＤＭＡ転送される。ここでは、このＤＭＡ転送回数が、ｆｒｏｎｔ２を用いてカウントされる。つまり、ＤＭＡ転送する毎に、ＤＭＡ転送された音声データのサンプル数分、ｆｒｏｎｔ２をカウントしていく。
　したがって、主系側のＯＳ１２０が正常に動作している場合には、ｆｒｏｎｔとｆｒｏｎｔ２を同じ位置から開始させた後に、ｆｒｏｎｔ２はｆｒｏｎｔに追従して変化する。これに対して、主系側のＯＳ１２０が動作不能となってしまった場合には、音声データのデキューが途中で停止し、ｆｒｏｎｔのカウントが停止する。また、主系側のＯＳ１２０)が動作不能になることでＤＭＡ転送が行われなくなるために、ｆｒｏｎｔ２についてもカウントが停止し、ｆｒｏｎｔ２の位置は更新されない。
　ここで、図７に示すように、主系側のＯＳ１２０が動作不能となって、ｆｒｏｎｔ及びｆｒｏｎｔ２が停止した場合に、切り替えた予備系側のドライバコア部１１４が、呼び出したソフトウェアミキサ関数を用いて、ｆｒｏｎｔが示す位置から音声データのデキューを開始した状況を想定する。この状況において、ｆｒｏｎｔを用いて示す位置から音声データのデキューを開始すると、欠損している可能性のある音声データをデキューすることになり、音声データの整合性を保証することができない。このため、主系側のＯＳ１２０が動作不能となって、ｆｒｏｎｔ及びｆｒｏｎｔ２が停止した場合に、切り替えた予備系側のドライバコア部１１４が、呼び出したソフトウェアミキサ関数を用いて、ｆｒｏｎｔ２が示す位置から音声データのデキューを開始する。このようにすることで、主系側のＯＳ１２０が動作不能となるよりも前の音声データからデキューを開始することができるため、切り替えの前後での音声データの整合性を保証することができる。
　ここで、選択条件「音声ミキシング処理時間＜ＤＭＡ転送間隔≦(音声ミキシング処理時間×２)」を満たしてパターンＡを選択している場合には、ＤＭＡ転送用バッファ４４を参照して、ＤＭＡ転送用バッファ４４に格納されている音声データのサンプル数を－１したサンプル数分、ｆｒｏｎｔ２をカウントする。そして、ｆｒｏｎｔ２が示す位置から音声データのデキューを開始する。
　ここで、ＤＭＡ転送用バッファ４４に格納されている音声データのうち、欠損している可能性のある音声データは、主系側のドライバコア部１２７が最後に音声ミキシングして格納していた音声データとなる。したがって、このように、予備系側のドライバコア部１１４において、主系側のドライバコア部１２７が最後に音声ミキシングして格納していた音声データから音声ミキシング処理を引き継いで実行するようにすることで、切り替えの前後での音声データの整合性を保証することができる。つまり、予備系側のドライバコア部１１４は、サウンドキュー４１、４２、４３の位置のうち、ＤＭＡ転送用バッファ４４に格納されている音声データの格納量が示す位置よりも少なくとも１サンプル前の位置から、音声ミキシング処理を引き継いで実行する。
　また、このように、予備系側のドライバコア部１１４において、音声ミキシング処理を引き継いで実行するようにすることで、主系側から予備系側への切り替えの前後を通じての音声ミキシング処理時間を、ほぼ１回分の音声ミキシング処理時間とすることができる。そのため、「音声ミキシング処理時間＜ＤＭＡ転送間隔≦(音声ミキシング処理時間×２)」の条件となる場合にパターンＡを選択しても、Ｉ２Ｓアンダーランエラーを発生させることなく、主系側から予備系への切り替えを行うことができる。
　また、予備系側のＯＳ１１０へと切り替えた場合に、新しく主系側となった予備系側のドライバコア部１１４が音声ミキシング処理を行っている最中には、主系側であったドライバコア部１２７からのＤＭＡレジスタアクセスを禁止することで、音声データの整合性を保証する。例えば、主系側のＯＳ１２０が認識している共有メモリ(ＳＤＲＡＭ３０)上の周辺デバイス(Ｉ２Ｓデバイス１３、ＤＭＡＣ１５)のベースアドレスを、予備系側のドライバ管理部１１０が一時的に、ＳＤＲＡＭ３０上において未使用領域等の無効アドレスに変更する。これによって、切り替え前に主系であったＯＳ１２０がレジスタへとアクセスすることを禁止することができる。
　以上に説明した本実施の形態によれば、複数のＯＳ間で音声出力のＩ２Ｓバスを共有する構成において、片方のＯＳの動作が停止した場合においても、もう片方のＯＳ側からの音声出力が途切れることを防止することができる。そのときに、「音声ミキシング処理時間＜ＤＭＡ転送間隔≦(音声ミキシング処理時間×２)」となる場合であっても、画音同期の精度が低下しないパターンＡによって主系から予備系への切り替えを可能としている。そのため、画音同期の精度の低下を抑制しつつ、音切れの発生を防止することができる。
　また、本実施の形態によれば、予備系でＦＩＦＯ境界割り込みを受信したときの主系から予備系への切り替えの要否の判定は、ＯＳ間共有メモリに格納される音声データのサンプル数を参照するだけで可能である。そのため、処理速度を低下させることがない。
　また、本実施の形態では、ＦＩＦＯ境界割り込みを許可している期間も、数十ｍｓ毎のＤＭＡ転送サイクルのうちの数百μｓオーダーの期間である。そのため、予備系側でのパフォーマンスへの影響は非常に少ない。
　また、本実施の形態では、サウンドドライバを上位アプリＩ／Ｆ部とドライバコア部に分離しており、サンプリングレート変換機能を上位アプリＩ／Ｆ部に有するようにしている。したがって、主系側のドライバコア部のみが動作不能となった場合であっても、主系の上位アプリＩ／Ｆ部におけるサンプリングレート変換処理を継続することができる。そのため、予備系のドライバコア部に音声ミキシング処理の実行を切り替えることで、主系側のＯＳで生成される音声データも継続して再生することが可能である。
　なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。例えば、ＭＰＵ１０が２つのＯＳ１１０、１２０を備えている場合を例に説明したが、本発明はこれに限定されない。すなわち、ＭＰＵ１０が３つ以上のＯＳを備えるものとしてもよい。かかる場合には、予備系側のＯＳが複数存在することになる。
　上述した主系又は待機系における動作を実行するプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ－ＲＯＭ（Read Only Memory）、ＣＤ－Ｒ、ＣＤ－Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（random access memory））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
　この出願は、２００９年１１月１８日に出願された日本出願特願２００９－２６２５４５を基礎とする優先権を主張し、その開示の全てをここに取り込む。
１　　マルチコアシステム
１０、５０　　ＭＰＵ
１１、１２　　ＣＰＵ
１３　　Ｉ２Ｓデバイス
１４　　Ｉ２Ｃデバイス
１５　　ＤＭＡコントローラ
１６　　共通割り込み制御部
１７　　ＨＷタイマー
２０　　音声出力装置
２１、５１　　ＡＤＡＣ＆ＡＭＰ
２２　　スピーカー
３０　　ＳＲＡＭ
４０　　ＯＳ間共有メモリ
４１、４２、４３、８１、８２　　　　サウンドキュー
４４、６３、７３　　ＤＭＡ転送用バッファ
６１、６２　　プロセッサコア
６４　　音声出力部
７１、７２、１１０、１２０　　　　ＯＳ
７４、１３１　　　　ＦＩＦＯ
７５　　ＡＤＡＣ
１１１、１２１、１２２、１２３、７１１、７２１　　アプリ
１１２、１２５　　　　サウンドドライバ
１１３、１２６　　　　上位アプリＩ／Ｆ部
１１４、１２７　　　　ドライバコア部
１１５　　　　ドライバ管理部
１１６、１３０　　　　サンプリングレート変換機能
１２４　　　　サウンドサーバ
１２８　　　　ソフトウェアミキサ
１２９　　　　ＤＭＡ転送割り込みスレッド
６１０、６２０　　　　プログラム
７１２、７２２　　　　ミキシング済みサンプル数カウンタ

Claims (11)

  1. 　第１のプロセッサコア上で動作し、第１及び第２の音声データをミキシングして、当該ミキシングした合成音声データをＤＭＡ転送用バッファに格納する主系プログラムと、
    　第２のプロセッサコア上で動作し、前記主系プログラムの予備系として動作する予備系プログラムと、
    　前記ＤＭＡ転送用バッファから転送される合成音声データを順次格納し、当該格納した合成音声データを再生する音声出力手段と、を備え、
    　前記予備系プログラムは、前記ＤＭＡ転送用バッファに格納される合成音声データの格納量が、前記音声出力手段に格納される合成音声データの格納量に応じて定める所定のデータ量に達していない場合、前記主系プログラムが実行していた合成音声データのミキシング及び格納を引き継いて実行することを特徴とするマルチコアシステム。
  2. 　前記予備系プログラムは、前記音声出力手段に格納されている合成音声データの格納量が所定の単位減少する毎に、前記ＤＭＡ転送用バッファに格納される合成音声データの格納量が、前記音声出力手段に格納されている合成音声データの減少量に応じて定める所定の閾値に達しているか否かを判定し、当該所定の閾値に達してない場合に、前記主系プログラムが実行していた合成音声データのミキシング及び格納を引き継いて実行することを特徴とする請求項１に記載のマルチコアシステム。
  3. 　前記音声出力手段は、前記ＤＭＡ転送用バッファから転送される合成音声データをエンキューして、前記再生をする合成音声データがデキューされるＦＩＦＯバッファを有することを特徴とする請求項１に記載のマルチコアシステム。
  4. 　前記音声出力手段は、前記ＦＩＦＯバッファに格納されている合成音声データが所定の単位デキューされる毎に、前記予備系プログラムにＦＩＦＯ境界割り込みを出力し、
    　前記予備系プログラムは、前記音声出力手段からのＦＩＦＯ割り込みに応じて、前記ＤＭＡ転送用バッファに格納される合成音声データの格納量が、前記ＦＩＦＯバッファに格納されている合成音声データの格納量に応じて定める所定の閾値に達しているか否かを判定し、当該所定の閾値に達していない場合に、前記主系プログラムが実行していた合成音声データのミキシング及び格納を引き継いて実行することを特徴とする請求項３に記載のマルチコアシステム。
  5. 　前記マルチコアシステムは、前記ＤＭＡ転送用バッファに格納された合成音声データを前記ＦＩＦＯバッファに転送して、当該転送が完了した場合に、ＤＭＡ転送完了割り込みを前記予備系プログラムに出力するＤＭＡコントローラを更に有し、
    　前記予備系プログラムは、前記ＤＭＡコントローラからの前記ＤＭＡ転送完了割り込みに応じて、前記ＦＩＦＯ境界割り込みの出力を有効にするＦＩＦＯ境界割り込み開始要求を前記音声出力手段に出力し、
    　前記主系プログラムは、前記合成音声データのミキシング及び格納を完了した場合に、前記ＦＩＦＯ境界割り込みの出力を無効にするＦＩＦＯ境界割り込み停止要求を前記音声出力手段に出力することを特徴とする請求項４に記載のマルチコアシステム。
  6. 　前記主系プログラムは、第１のオペレーティングシステムと、前記第１のオペレーティングにおいて動作する第１のサウンドドライバを含み、
    　前記予備系プログラムは、第２のオペレーティングシステムと、前記第２のオペレーティングにおいて動作する第２のサウンドドライバを含み、
    　前記第２のサウンドドライバは、前記第１のサウンドドライバが実行していた合成音声データのミキシング及び格納を引き継いで実行することを特徴とする請求項１乃至５のいずれか１項に記載のマルチコアシステム。
  7. 　前記マルチコアシステムは、前記１の音声データが格納される第１のリングバッファと、前記第２の音声データが格納される第２のリングバッファとをさらに備え、
    　前記主系プログラムのサウンドドライバは、前記第１及び第２のリングバッファから前記第１及び第２の音声データを順次取得し、
    　前記第２のサウンドドライバは、前記合成音声データのミキシング及び格納を引き継いで実行する場合に、前記第１及び第２のリングバッファの位置のうち、前記ＤＭＡバッファに格納されている合成音声データの格納量が示す位置よりも少なくとも１サンプル前の位置から、前記第１及び第２の音声データのミキシング及び格納を引き継いで実行することを特徴とする請求項６に記載のマルチコアシステム。
  8. 　前記主系プログラムは、前記第１の音声データを生成する第１のアプリケーションプログラムを更に含み、
    　前記予備系プログラムは、前記第２の音声データを生成する第２のアプリケーションプログラムを更に含み、
    　前記第１のサウンドドライバは、前記第１のアプリケーションプログラムが生成した第１の音声データのサンプリングレートを変換して前記第１のリングバッファに格納するインタフェース手段と、前記合成音声データのミキシング及び格納を実行するドライバコア手段とを含み、
    　前記第２のサウンドドライバは、前記第２のアプリケーションプログラムが生成した第２の音声データのサンプリングレートを変換して前記第２のリングバッファに格納するインタフェース手段と、前記合成音声データのミキシング及び格納を実行するドライバコア手段と含むことを特徴とする請求項７に記載のマルチコアシステム。
  9. 　前記音声出力手段は、Ｉ２Ｓデバイスと、ＤＡコンバータを含む音声出力装置とを含み、
    　前記Ｉ２Ｓデバイスは、前記ＤＭＡ転送用バッファから転送される合成音声データをエンキューして、前記再生をする合成音声データがデキューされるＦＩＦＯバッファを有し、
    　前記音声出力装置は、前記ＦＩＦＯバッファからデキューされた合成音声データをアナログ信号に変換して再生することを特徴とする請求項１に記載のマルチコアシステム。
  10. 　第１のプロセッサコア上で動作する主系プログラムが、第１及び第２の音声データをミキシングして、当該ミキシングした合成音声データをＤＭＡ転送用バッファに格納し、
    　音声出力手段が、前記ＤＭＡ転送用バッファから転送される合成音声データを順次格納し、当該格納した合成音声データを再生し、
    　第２のプロセッサコア上で動作し、前記主系プログラムの予備系として動作する予備系プログラムが、前記ＤＭＡ転送用バッファに格納される合成音声データの格納量が、前記音声出力手段に格納される合成音声データの格納量に応じて定める所定のデータ量に達しているか否かを判定し、
    　前記所定のデータ量に達していると判定した場合に、前記予備系プログラムが、前記主系プログラムが実行していた合成音声データのミキシング及び格納を引き継いて実行するマルチコアシステムの制御方法。
  11. 　主系プログラムとは異なるプロセッサコア上で、当該主系プログラムの予備系として動作するプログラムであって、
    　転送されてくる合成音声データを順次格納し、当該格納した合成音声データを再生する音声出力手段に対して転送され、前記主系プログラムが第１及び第２の音声データをミキシングした合成音声データが格納されるＤＭＡ転送用バッファに格納される合成音声データの格納量が、前記音声出力手段に格納される合成音声データの格納量に応じて定める所定のデータ量に達しているか否かを判定する処理と、
    　前記所定のデータ量に達していると判定した場合に、前記主系プログラムが実行していた合成音声データのミキシング及び格納を引き継いて実行する処理と、を前記プロセッサコアに実行させることを特徴とするプログラムが格納された非一時的な可読媒体。
PCT/JP2010/004911 2009-11-18 2010-08-04 マルチコアシステム、マルチコアシステムの制御方法及びプログラムが格納された非一時的な可読媒体 WO2011061878A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US13/502,601 US8892230B2 (en) 2009-11-18 2010-08-04 Multicore system, control method of multicore system, and non-transitory readable medium storing program
JP2011541787A JP5382133B2 (ja) 2009-11-18 2010-08-04 マルチコアシステム、マルチコアシステムの制御方法及びプログラム
CN201080052247.8A CN102667745B (zh) 2009-11-18 2010-08-04 多核系统、多核系统的控制方法以及在非暂态可读介质中存储的程序

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2009262545 2009-11-18
JP2009-262545 2009-11-18

Publications (1)

Publication Number Publication Date
WO2011061878A1 true WO2011061878A1 (ja) 2011-05-26

Family

ID=44059366

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/004911 WO2011061878A1 (ja) 2009-11-18 2010-08-04 マルチコアシステム、マルチコアシステムの制御方法及びプログラムが格納された非一時的な可読媒体

Country Status (4)

Country Link
US (1) US8892230B2 (ja)
JP (1) JP5382133B2 (ja)
CN (1) CN102667745B (ja)
WO (1) WO2011061878A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016537717A (ja) * 2013-12-23 2016-12-01 インテル・コーポレーション 複数のハイブリッドプロセッサコアを含むシステムオンチップ（ＳｏＣ）

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011061878A1 (ja) * 2009-11-18 2011-05-26 日本電気株式会社 マルチコアシステム、マルチコアシステムの制御方法及びプログラムが格納された非一時的な可読媒体
US9236064B2 (en) * 2012-02-15 2016-01-12 Microsoft Technology Licensing, Llc Sample rate converter with automatic anti-aliasing filter
EP2923279B1 (en) * 2012-11-21 2016-11-02 Coherent Logix Incorporated Processing system with interspersed processors; dma-fifo
CN104516779B (zh) * 2013-09-27 2020-03-24 联想(北京)有限公司 一种系统切换方法及芯片
US10467696B1 (en) * 2015-07-31 2019-11-05 Integral Development Corp. Timing mechanisms to enhance the security of online networks
TWI643185B (zh) * 2017-04-26 2018-12-01 瑞昱半導體股份有限公司 音訊處理裝置及方法
CN109313566B (zh) * 2017-12-27 2022-06-07 深圳前海达闼云端智能科技有限公司 一种虚拟机的音频播放方法及其装置、移动终端
JP6695955B1 (ja) 2018-11-27 2020-05-20 レノボ・シンガポール・プライベート・リミテッド 信号処理装置、制御方法、及びプログラム
DE102019203130A1 (de) * 2019-03-07 2020-09-10 Continental Automotive Gmbh Nahtlose Audioübergabe in einem Mehrprozessor-Audiosystem
CN111258937B (zh) * 2020-01-23 2021-08-03 烽火通信科技股份有限公司 一种环式链表dma的传输方法及系统
CN111338998B (zh) * 2020-02-20 2021-07-02 深圳震有科技股份有限公司 基于amp系统的flash访问处理方法及装置
CN111427806A (zh) * 2020-03-23 2020-07-17 深圳震有科技股份有限公司 一种双核amp系统共用串口的方法、存储介质及智能终端
CN111427817B (zh) * 2020-03-23 2021-09-24 深圳震有科技股份有限公司 一种amp系统双核共用i2c接口的方法、存储介质及智能终端
CN115696173A (zh) * 2022-09-14 2023-02-03 合肥杰发科技有限公司 一种芯片、车用音源播放方法、车载设备及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006085386A (ja) * 2004-09-15 2006-03-30 Sony Corp 情報処理装置および方法、並びにプログラム
JP2006146937A (ja) * 2004-11-24 2006-06-08 Toshiba Corp データのリアルタイム処理を行うための方法及びシステム

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5357511A (en) * 1993-03-22 1994-10-18 Peak Audio, Inc. Distributed processing in a digital audio mixing network
JP3193525B2 (ja) * 1993-05-31 2001-07-30 キヤノン株式会社 情報処理装置
ATE188793T1 (de) * 1994-10-12 2000-01-15 Touchtunes Music Corp Intelligentes system zur numerischen audio- visuellen reproduktion
US5850628A (en) * 1997-01-30 1998-12-15 Hasbro, Inc. Speech and sound synthesizers with connected memories and outputs
JPH11196386A (ja) * 1997-10-30 1999-07-21 Toshiba Corp コンピュータシステムおよびクローズドキャプション表示方法
FR2849327A1 (fr) * 2002-12-20 2004-06-25 St Microelectronics Sa Procede et dispositif de decodage audio/video, circuit pilote video et boitier decodeur l'incorporant
US7529467B2 (en) * 2004-02-28 2009-05-05 Samsung Electronics Co., Ltd. Storage medium recording text-based subtitle stream, reproducing apparatus and reproducing method for reproducing text-based subtitle stream recorded on the storage medium
JP4605700B2 (ja) 2004-07-28 2011-01-05 武蔵精密工業株式会社 歯車の歯面における歯すじの修正方法
US7774512B2 (en) * 2005-02-08 2010-08-10 Sony Computer Entertainment Inc. Methods and apparatus for hybrid DMA queue and DMA table
US7603505B2 (en) * 2005-07-15 2009-10-13 Mattel, Inc. Interactive electronic device with digital and analog data links
US7590772B2 (en) * 2005-08-22 2009-09-15 Apple Inc. Audio status information for a portable electronic device
US7814166B2 (en) * 2006-01-27 2010-10-12 Sony Computer Entertainment Inc. Methods and apparatus for virtualizing an address space
DE102006055930A1 (de) 2006-11-27 2008-05-29 Siemens Ag Bildverarbeitungssystem zum Verarbeiten wenigstens eines Bild-Datensatzes mit einer schnellen Bildverarbeitungsvorrichtung und Verfahren zum Bildverarbeiten
US8037221B2 (en) * 2008-01-16 2011-10-11 International Business Machines Corporation Dynamic allocation of DMA buffers in input/output adaptors
JP2009190103A (ja) 2008-02-13 2009-08-27 Hitachi High-Tech Control Systems Corp 半導体搬送装置
US20090248300A1 (en) * 2008-03-31 2009-10-01 Sony Ericsson Mobile Communications Ab Methods and Apparatus for Viewing Previously-Recorded Multimedia Content from Original Perspective
CN100562864C (zh) * 2008-06-03 2009-11-25 浙江大学 一种嵌入式异构多核体系片上通信的实现方法
JP4683116B2 (ja) * 2008-11-12 2011-05-11 ソニー株式会社 情報処理装置、情報処理方法、情報処理プログラムおよび撮像装置
JP5099090B2 (ja) 2009-08-19 2012-12-12 日本電気株式会社 マルチコアシステム、マルチコアシステムの制御方法、及びマルチプロセッサ
US20120204183A1 (en) * 2009-09-02 2012-08-09 Plurality Ltd. Associative distribution units for a high flowrate synchronizer/schedule
WO2011061878A1 (ja) * 2009-11-18 2011-05-26 日本電気株式会社 マルチコアシステム、マルチコアシステムの制御方法及びプログラムが格納された非一時的な可読媒体

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006085386A (ja) * 2004-09-15 2006-03-30 Sony Corp 情報処理装置および方法、並びにプログラム
JP2006146937A (ja) * 2004-11-24 2006-06-08 Toshiba Corp データのリアルタイム処理を行うための方法及びシステム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016537717A (ja) * 2013-12-23 2016-12-01 インテル・コーポレーション 複数のハイブリッドプロセッサコアを含むシステムオンチップ（ＳｏＣ）

Also Published As

Publication number Publication date
US8892230B2 (en) 2014-11-18
US20120221134A1 (en) 2012-08-30
JP5382133B2 (ja) 2014-01-08
JPWO2011061878A1 (ja) 2013-04-04
CN102667745A (zh) 2012-09-12
CN102667745B (zh) 2015-04-08

Similar Documents

Publication Publication Date Title
JP5382133B2 (ja) マルチコアシステム、マルチコアシステムの制御方法及びプログラム
US8719628B2 (en) Multi-core system, method of controlling multi-core system, and multiprocessor
US6898723B2 (en) Method for verifying clock signal frequency of computer sound interface that involves checking whether count value of counter is within tolerable count range
WO2013185636A1 (zh) 控制数据传输过程中的中断的方法
US20210109681A1 (en) Nvme-based data writing method, apparatus, and system
JP2008090375A (ja) 割込み制御システム、およびこれを利用した記憶制御システム
US20060041895A1 (en) Systems and methods for interfacing with codecs across an architecture optimized for audio
CN109599133B (zh) 语言音轨的切换方法、装置、计算机设备及存储介质
JP2011524574A (ja) タスクロードを測定するための方法およびシステム
US20060095637A1 (en) Bus control device, arbitration device, integrated circuit device, bus control method, and arbitration method
US7861012B2 (en) Data transmitting device and data transmitting method
JP5375650B2 (ja) マルチコアシステム、マルチコアシステムの制御方法及びプログラム
US7321945B2 (en) Interrupt control device sending data to a processor at an optimized time
EP1366421B1 (en) Digital signal processor interrupt accelerator
TW591510B (en) Control method for data transfer control unit
JP2006302343A (ja) 情報記録再生装置
JP2018520398A (ja) マルチメディアストリームの送信の改善
JP4507672B2 (ja) オーディオ再生装置およびクロック周波数制御方法
JP2011095966A (ja) アクセスコントローラ
JP2008108126A (ja) データ転送制御装置及びそのバスアクセス調停方法
CN113455011B (zh) 用于媒体设备中的数据管理的系统和方法
US20220374375A1 (en) Method of operating audio subsystem for usb module, system-on-chip performing the same and method of operating system-on-chip using the same
KR20090065253A (ko) ＭＭｏＩＰ 데이터의 전송 효율을 위한 직접 메모리 접근제어 장치 및 그 방법
JP4023332B2 (ja) 記録再生装置
JP2006113716A (ja) 半導体集積回路

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201080052247.8

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10831278

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 13502601

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2011541787

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10831278

Country of ref document: EP

Kind code of ref document: A1