JP2014041480A - Data processor and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To efficiently control a processing timing about a thread to perform the processing of media data.SOLUTION: A data processor for processing media data comprises media data processing means for performing the processing of the media data by using a thread in accordance with the control of application processing means. The thread comprises: data processing means to be periodically started for performing processing related to media data; and timer means for counting a time by using a counter in which a counter value is added each time the data processing means is started. The data processing means performs time measurement related to the processing to be performed by the data processing means by using the timer means in accordance with the control of the application processing means.

Description

  The present invention relates to a data processing apparatus and program, and can be applied to, for example, middleware that processes media data in units of threads.

  A server that performs data processing of media data (for example, data such as voice and video) related to a SIP terminal may be constructed using middleware including a library (data processing program) for performing real-time media communication. .

  For example, when newly developing a server that operates using an IVR (Interactive Voice Response) device or a media server function such as a conference call server, data processing of media data (for example, encoding conversion processing) ) And the basic operation of media data relay processing itself is common. Therefore, for media data processing, development using middleware equipped with a library for processing media data provides benefits such as shortening the development period, reducing development costs, and improving the quality of the developed product. It is done.

  By the way, in a server that performs data processing of telephone voice data such as IVR, since it is necessary to process a large number of calls at the same time, a configuration in which a thread is assigned to each call and processing is generally performed. As conventional techniques for performing telephone voice data processing in units of threads, for example, there are techniques described in Patent Documents 1 to 3.

  In Patent Document 1, in order to easily realize efficient processing of a child thread generated in a parent thread generated for each call, processing is performed by adjusting between child threads, and complicated processing in the parent thread is performed. Exclusive control is not performed.

  Japanese Patent Application Laid-Open No. 2004-228688 describes that a computer using a single CPU efficiently processes audio data on an OS that implements a multitasking environment using a TSS (Time Sharing System). . In Patent Document 2, the TSS does not depend on the quantum (processing unit time) assigned to each task, and by mixing the data processing of a plurality of tasks in one quantum, it does not depend on the TSS specification (quantum) and is efficient. Voice data processing can be performed.

  Japanese Patent Application Laid-Open No. 2004-228688 describes that the process is forcibly terminated even when a memory outside a predetermined area reserved in advance by each thread is used in a process in which a plurality of threads operate. In Patent Document 3, when a thread that uses a memory outside a predetermined area is generated, only the thread is deleted only when it is determined that there is no influence on the entire process.

JP 2003-150391 A JP 2006-185303 A JP 2005-284630 A

  By the way, in a server using middleware that processes media data, it is desirable that processing timing is synchronized between the middleware and an application that operates using the middleware. For example, when the playback timing of an audio file is controlled by a server such as IVR, the processing waiting time (actual time) on the application side and the processing amount (for example, the number of packets) processed by the thread on the middleware side are synchronized. It is desirable that Therefore, in such a case, in the conventional media server, it is necessary to correct the waiting time on the application side according to the processing amount on the middleware side. As a method for solving such a problem, for example, it is conceivable to synchronize a large number of threads and applications operating in the middleware using a common clock. In this case, the convenience of middleware (application development) Efficiency) and versatility (restricting application specifications), and increasing the amount of middleware processing.

  Further, even when the techniques described in Patent Documents 1 to 3 are applied to the middleware of the media server, there is no description about a configuration for efficiently synchronizing the processing timings of the application and a large number of threads in the middleware.

  Therefore, there is a demand for a data processing apparatus and program that can efficiently control the processing timing of threads that process media data.

  The data processing apparatus of the first aspect of the present invention comprises (1) media data processing means for processing media data using a thread in accordance with control of the application processing means, and (2) the thread is (2- 1) Time measurement is performed using a data processing unit that periodically starts and performs processing related to media data, and (2-2) a counter to which a counter value is added each time the data processing unit starts. (2-3) The data processing means performs time measurement related to processing performed by the data processing means using the timer means in accordance with control of the application processing means. And

  The data processing program of the second aspect of the present invention causes a computer to function as (1) media data processing means for processing media data using threads in accordance with control of application processing means, and (2) the threads are (2-1) Data processing means that is periodically activated to perform processing relating to media data, and (2-2) Time using a counter to which a counter value is added each time the data processing means is activated. (2-3) The data processing means uses the timer means to measure the time associated with the processing performed by the data processing means in accordance with the control of the application processing means. It is characterized by performing.

  According to the present invention, it is possible to efficiently control the processing timing of a thread that processes media data.

It is the block diagram shown about the functional structure of the data processor which concerns on embodiment. It is the timing chart shown about the example (the 1) of the reproduction | regeneration schedule of the audio | voice file which concerns on embodiment. It is the timing chart shown about the example (the 2) of the reproduction | regeneration schedule of the audio | voice file which concerns on embodiment. It is the sequence diagram (the 1) shown about operation | movement of the data processor which concerns on embodiment. It is the sequence diagram (the 2) shown about operation | movement of the data processor which concerns on embodiment. It is the sequence diagram (the 3) shown about operation | movement of the data processor which concerns on embodiment.

(A) Main Embodiment Hereinafter, an embodiment of a data processing apparatus and a program according to the present invention will be described in detail with reference to the drawings.

(A-1) Configuration of Embodiment FIG. 1 is a block diagram showing a connection configuration between the data processing device 1 and peripheral devices of this embodiment.

  The data processing apparatus 1 is a media server that provides a media data processing service to the terminals 2 (2-1, 2-2) connected to the network 6. In this embodiment, as an example, the data processing apparatus 1 is described as a server (media server) that functions as an IVR. However, the contents of the media data processing service provided by the data processing apparatus 1 and the destinations of the services It is not limited.

  As shown in FIG. 1, it is assumed that the data processing apparatus 1 is constructed on a platform in which a general-purpose OS 20 is mounted on hardware 10 such as an existing PC or workstation. As the general-purpose OS 20, for example, a general-purpose OS such as Linux (registered trademark) or Windows (registered trademark) can be applied.

  On the general-purpose OS 20, a signaling processing unit 50 that performs signaling processing and a media data processing unit 30 that performs media data processing using the thread 31 are mounted. In addition, the data processing apparatus 1 includes an application 40 that provides a media data processing service using the media data processing unit 30 and the signaling processing unit 50.

  That is, the application 40 functions as an application that provides the IVR service to the terminals 2 (2-1, 2-2) using the media data processing unit 30 and the signaling processing unit 50.

  The media data processing unit 30 is middleware that provides a media data service to communication devices (such as the terminal 2) on the network 6 in accordance with the control of the application 40. When a media data service is requested for one call (session) from the application 40, the media data processing unit 30 generates a thread 31 for the call. The media data processing unit 30 is provided with a library of media data processing (collection of processing programs) executed by the thread 31, and the thread 31 uses these libraries to respond to the control of the application 40. Execute media data processing. FIG. 1 shows a state in which N threads 31 (31-1 to 31-N) are generated in the media data processing unit 30. Note that the number of threads 31 generated simultaneously in the media data processing unit 30 is not limited.

  The media data processing unit 30 can be realized by causing a computer (hardware 10) having a processor, a memory, and the like to execute the data processing program of the embodiment.

  The API processing unit 32 is an interface for accepting a control instruction from the application 40 (accepting a function call) by an API (Application Program Interface). The application 40 can execute media data processing using the media data processing unit 30 by supplying a control instruction based on the specification of the API processing unit 32 (API specification). API functions include, for example, session start / stop, audio file playback start / stop, and the like.

  In the media data processing unit 30, when a session start is instructed from the application 40 to the API processing unit 32, a thread 31 corresponding to the session is generated. In the application 40, the ID of each session and the ID of the thread 31 corresponding to each session are managed in association with each other.

  When there is a control instruction for any one of the threads 31 from the application 40, the API processing unit 32 assigns the control to the thread 31 (for example, identified by the thread ID or the like) corresponding to the control instruction. Communicate instructions.

  In this embodiment, the API processing unit 32 and each thread 31 are not configured to communicate directly, but are configured to transmit information using the shared memory 36 as a medium. This is a configuration for efficiently transmitting information between the API processing unit 32 and each thread 31 because all threads 31 are not always activated. Therefore, when the control instruction from the application 40 is transmitted to any one of the threads 31, the API processing unit 32 stores in the shared memory 36 information (information describing the instruction content) with the thread ID attached to the shared memory 36. To do. Each thread 31 checks the shared memory 36 every time it is activated, and if information on an instruction to itself is stored, acquires that information and performs processing.

  The event queue 33 is a queue that temporarily holds an event (for example, session start or the like) that has occurred in each thread 31 and reports it to the application 40.

  The event queue 35 temporarily holds an event (hereinafter referred to as a “timeout event”) that occurs due to a timeout (timer expiration) due to a process (hereinafter referred to as “timer processing”) for measuring a predetermined time by the thread 31. This is a queue for performing processing to be supplied to the callback thread 34. When the callback thread 34 is supplied with a timeout event from the thread 31, the callback thread 34 causes the callback processing unit 41 of the application 40 to execute a callback process corresponding to the thread 31. Callback processing refers to processing of the next step to be executed from the application 40 to the thread 31 when a timeout event occurs in the thread 31 (for example, a control instruction for stopping playback of an audio file). The media data processing unit 30 (callback thread 34) prompts execution.

  Then, when a timeout event is supplied, the callback thread 34 notifies the callback processing unit 41 of the application 40 of a callback process corresponding to the timeout event (processing of a control instruction to the thread 31 that issued the timeout event). ) Is executed. For example, when the application 40 causes the thread 31 to execute a timer process, information defining a callback process corresponding to the timer process is set in the callback processing unit 41. When the thread 31 issues a timeout event corresponding to the timer process, the callback processing unit 41 causes the application 40 main body to execute a preset callback process (control instruction for the thread 31). Shall.

  As described above, in the data processing device 1, it is assumed that a transmission path (callback thread 34 and event queue 35) dedicated to callback processing accompanying a timer event from the thread 31 to the application 40 is set.

  In this embodiment, it is assumed that the API processing unit 32 and the thread 31 are configured to be unable to operate simultaneously by exclusive control because access to a shared resource (memory, variable, etc.) occurs. . For this reason, in the data processing device 1, a callback thread 34 is added separately from the thread 31 so that processing between the API processing unit 32 and the thread 31 competes to prevent deadlock.

  In this embodiment, in the media data processing unit 30, each thread 31 is periodically activated (hereinafter referred to as “periodic activation”) to perform processing. In this embodiment, as an example, when a call (session) related to media data processing is activated, the thread 31 is periodically activated at a cycle of 20 ms, and when the cycle is activated, media data processing or the like is executed as media data processing. To do.

  Here, when each thread 31 is periodically activated, it is assumed that the processing of media data for the period activation interval is executed. For example, it is assumed that the thread 31 performs audio data encoding and RTP (Real-time Transport Protocol) packet generation / transmission processing from an audio data file. In this case, the thread 31 performs encoding and RTP packet generation / transmission processing on the audio data for 20 ms each time the cycle is activated.

  The storage destination of the media data processed by each thread 31 is not limited. For example, it may be stored in a hard disk such as a general-purpose server, or may be a file on another server connected by the network 6. Or may be expanded on a memory. Each thread 31 generates an event in response to a session start, session stop, audio file playback start, audio file playback stop, and the like, and supplies (attaches) the event to the event queue 33. In this embodiment, as an example, each thread 31 acquires the audio file F1 held by the application 40, encodes the audio data of the audio file F1 (for example, encodes it with a Codec such as G.711), and so on. , It is assumed that a process of inserting into the payload of the RTP packet and sending it to the terminal 2 is performed. Hereinafter, a process in which each thread 31 generates and transmits an RTP packet from the audio file F1 is also referred to as a “reproduction process”.

  Each thread 31 includes a timer processing unit 311 that performs time measurement using a counter that is incremented each time the cycle is activated. Each thread 31 performs a timer process instructed by the application 40 at a timing based on the timer processing unit 311. For example, when there is a control instruction from the application 40 for an audio file reproduction process for one second (a timer process for counting one second and an audio file reproduction process), 50 periodic activations (20 ms × 50 = 1 s) are performed. When performed, it is handled as one second of media data processed.

(A-2) Operation | movement of embodiment Next, operation | movement of the data processor 1 of this embodiment which has the above structures is demonstrated. As described above, in this embodiment, the data processing device 1 functions as an IVR. Here, as an example, a case will be described in which the data processing device 1 performs a reproduction process of the audio file F1 (transmission processing of an RTP packet into which audio data is inserted) for the terminal 2-1. Specifically, it is assumed that the thread 31-1 performs an audio file reproduction process based on a control instruction (control instruction using an API) from the application 40.

  In FIG. 2, after reproducing the audio file F1 for 10 seconds from the timing T100 to the timing T101, the audio file F1 is reproduced again from the timing T102 to the timing T103. It shows about processing. In other words, in FIG. 2, the operation of reproducing the audio file F1 is performed twice, and the reproduction interval (silence period) is 5 seconds. Note that the playback time of the audio file F1 may be controlled by preparing a 10-sec audio file and completing the playback, but in this embodiment, it is described as being controlled by timer processing.

  The format (description language) for describing the playback timing of the audio file as shown in FIG. 2 in the application 40 is not limited. For example, MSCML (IETF RFC5022: (Media Server Control I Markup Language (MSCML) and Protocol) )) May be used.

  In MSCML, playback timing can be described using parameters such as delay, repeat, and duration. “Delay” is a parameter indicating that playback is delayed by a specified time before file playback (however, it is not applied before the first playback). In addition, there is no sound during the delay period. “Repeat” is a parameter indicating the number of times an audio file is played. It is possible to specify unlimited (∞) repeat playback by setting a predetermined parameter in “repeat”. “Duration” is a parameter indicating the playback time (position) of the audio file. When the time indicated by duration is reached from the start of the session (call), the session (call) is automatically disconnected, and the audio file playback is also terminated.

  Therefore, when the timing shown in the timing chart of FIG. 2 is described by MSCML parameters, “audio file playback time: 10 sec, delay: 5 sec, repeat: 2, duration: − (none)”.

  FIG. 3 is a timing chart showing the playback timing when “audio file playback time: 10 sec, delay: 5 sec, repeat: unlimited (∞), duration: 35 sec”.

  In the application 40 of this embodiment, based on the playback timing control information described in MSCML, the control content for the thread 31-1 (the content of the control instruction and the content set as the callback processing associated with the next timeout) is stored. A decision is made.

  Next, the detailed operation inside the data processing apparatus 1 when the audio file is played back at the timing as shown in FIG. 3 will be described with reference to the sequence diagrams of FIGS.

  4 to 6, each of the periodic activations generated at intervals of 20 msec in the thread 31-1 is given any one of B <b> 101 to B <b> 1351. In FIGS. 4 to 6, the processing of the steps illustrated inside the broken line relating to each periodic activation indicates that the processing is executed in the periodic activation in the thread 31-1.

  Also, as an initial state of the flowcharts of FIGS. 4 to 6, description will be made assuming that the thread 31-1 is generated in the media data processing unit 30 based on the control instruction (session start) of the application 40.

  Then, it is assumed that the application 40 gives a command to the API processing unit 32 to start a timer process that counts 10 seconds related to the thread 31-1 and to start reproduction of the audio file F1. Then, the API processing unit 32 stores the control instruction describing the contents of the control instruction in the shared memory 36 (S101, S102).

  Thereafter, the thread 31-1 is periodically activated and the process of the periodic activation B101 (the processes of steps S103 to S106) is executed.

  In the periodic activation B101, the thread 31-1 first confirms the content of the shared memory 36, recognizes that the control instruction to itself is stored, and acquires the control instruction (S103).

  Then, the thread 31-1 initializes (0) the counter value of the timer processing unit 311 based on the content of the acquired control instruction and starts it, and measures 10 seconds (time until the counter value reaches 500). The timer process for performing is started (S104).

  Then, the thread 31-1 starts the reproduction process of the audio file F1 based on the content of the acquired control instruction. The thread 31-1 performs a reproduction process on the audio data of 20 msec of the audio file F1 in the stage of the periodic activation B101. Further, the thread 31-1 performs a process of incrementing the counter value of the timer processing unit 311 (S105). When the reproduction process of the audio file F1 is started, the thread 31-1 notifies the event queue 33 of an event indicating that the reproduction process has been started (S106). Thus, the process in the periodic activation B101 by the thread 31-1 is completed.

  Then, the event queue 33 notified of the event of the reproduction start process holds the event and notifies the application 40 (S107).

  Then, at the timing of the next periodic activation B102, the thread 31-1 performs reproduction processing on the audio data of the next 20 msec of the audio file F1, and further increments the counter value of the timer processing unit 311. Processing is performed (S108).

  Then, the thread 31-1 repeats the processing of the same processing (step S106) as the periodic activation B102, and the 500th periodic activation counted from the periodic activation B101 with the counter value of the timer processing unit 311 reaching 499. It is assumed that B600 is greeted. In the periodic activation B600, the thread 31-1 executes processing of steps S202 to S203 described later.

  In the periodic activation B600, the thread 31-1 performs a reproduction process on the audio data of the next 20 msec of the audio file F1, and further performs a process of incrementing the counter value of the timer processing unit 311 (S201). At this time, in the thread 31-1, the counter value of the timer processing unit 311 becomes 500, and the timeout of the timer processing unit 311 is detected (S202). Then, when detecting a timeout of the timer processing unit 311, the thread 31-1 supplies a timeout event to the event queue 35 (S 203). Thus, the process in the periodic activation B600 by the thread 31-1 is completed.

  Then, the event queue 35 supplies the supplied timeout event to the callback thread 34 (S203). Then, the callback thread 34 requests a callback process corresponding to the supplied timeout event from the application 40 (callback processing unit 41) (S204). Here, in the application 40 (callback processing unit 41), as the next callback processing for the thread 31-1, the control for stopping the reproduction of the audio file and the start control for the timer processing for measuring 5 seconds are set. It shall be.

  The application 40 (callback processing unit 41) then stops the playback of the audio file F1 related to the thread 31-1, and counts 5 seconds with respect to the API processing unit 32 according to the definition of the next callback processing. A process start control instruction is issued (S205, S207). Then, the API processing unit 32 stores the control instruction describing the contents of the control instruction in the shared memory 36 (S206, S208).

  Thereafter, the thread 31-1 is periodically activated to execute the process of the periodic activation B601 (the processes of steps S209 to S212).

  In the periodic activation B601, the thread 31-1 first confirms the content of the shared memory 36, recognizes that the control instruction to itself is stored, and acquires the control instruction (S209).

  Then, the thread 31-1 performs reproduction stop processing for the audio file F1 based on the content of the acquired control instruction (S210). When the playback stop process for the audio file F1 is performed, the thread 31-1 notifies the event queue 33 of an event indicating that the playback stop process has been executed (S211).

  The thread 31-1 initializes (0) the counter value of the timer processing unit 311 based on the content of the acquired control instruction and starts it up for 5 seconds (time until the counter value reaches 250). The timer process for performing is started (S212). Thus, the process in the periodic activation B601 by the thread 31-1 is completed.

  Then, the event queue 33 notified of the reproduction process stop event holds the event and notifies the application 40 (S213).

  Then, the thread 31-1 repeats cyclic activation thereafter, and increments the counter value of the timer processing unit 311 each time it is cyclically activated. Then, it is assumed that the thread 31-1 has reached the 249th periodic activation B850 counted from the periodic activation B601 in a state where the counter value of the timer processing unit 311 reaches 249. In the periodic activation B850, the thread 31-1 executes processing of steps S301 and S302 described later.

  In the periodic activation B850, the thread 31-1 performs a process of incrementing the counter value of the timer processing unit 311. At this time, in the thread 31-1, the counter value of the timer processing unit 311 becomes 250, and the timeout of the timer processing unit 311 is detected (S301). Then, when detecting the timeout of the timer processing unit 311, the thread 31-1 supplies a timeout event to the event queue 35 (S 302). Thus, the process in the periodic activation B850 by the thread 31-1 is completed.

  It should be noted that between the periodic activations B601 to B850, the thread 31-1 may perform silent audio data reproduction processing (reproduction processing of silent audio data for 20 msec for each periodic activation). However, when the terminal 2-1 is configured to output silent sound while the RTP packet is not supplied, the above-described reproduction processing related to the silent sound from the thread 31-1 is not necessary. .

  Then, the event queue 35 supplies the supplied timeout event to the callback thread 34. Then, the callback thread 34 requests a callback process corresponding to the supplied timeout event from the application 40 (callback processing unit 41) (S303). Here, in the application 40 (callback processing unit 41), as the next callback processing for the thread 31-1, the playback start control of the audio file F1 and the start control of the timer processing that counts 10 seconds are set. It shall be.

  Then, the application 40 (callback processing unit 41) controls the start of reproduction of the audio file F1 and the start of the timer process that measures 10 seconds with respect to the API processing unit 32 according to the setting of the next callback processing. Is instructed (S304, S306). Then, the API processing unit 32 stores the control instruction describing the content of the control instruction in the shared memory 36 (S305, S307).

  Thereafter, the thread 31-1 is periodically activated, and the process of periodic activation B851 (the processes of steps S308 to S310) is executed.

  In the periodic activation B851, first, the thread 31-1 confirms the content of the shared memory 36, recognizes that the control instruction to itself is stored, and acquires the control instruction (S308).

  Then, the thread 31-1 initializes (0) the counter value of the timer processing unit 311 based on the content of the acquired control instruction and starts it, and measures 10 seconds (time until the counter value reaches 500). The timer process for performing is started (S309).

  Then, the thread 31-1 starts reproduction processing of the audio file F1 based on the content of the acquired control instruction, and performs reproduction processing on the audio data of the first 20 msec of the audio file F1. Further, the thread 31-1 performs a process of incrementing the counter value of the timer processing unit 311 (S310).

  When the playback process of the audio file F1 is started, the thread 31-1 notifies the event queue 33 of an event indicating that the playback process has started (S311). Thus, the process in the periodic activation B851 by the thread 31-1 is completed.

  Then, the event queue 33 notified of the reproduction start process event holds the event and notifies the application 40 (S312).

  Then, it is assumed that the thread 31-1 repeats the reproduction process by periodic activation, and reaches the 500th periodic activation B1350 counted from the periodic activation B851 in a state where the counter value of the timer processing unit 311 reaches 499. In the periodic activation B1350, the thread 31-1 executes processing of steps S401 to S403 described later.

  In periodic activation B1350, the thread 31-1 performs a reproduction process on the audio data of the next 20 msec of the audio file F1, and further performs a process of incrementing the counter value of the timer processing unit 311 (S401). At this time, in the thread 31-1, the counter value of the timer processing unit 311 becomes 500, and the timeout of the timer processing unit 311 is detected (S402). Then, when detecting a timeout of the timer processing unit 311, the thread 31-1 supplies a timeout event to the event queue 35 (S 403). Thus, the process in the periodic activation B1350 by the thread 31-1 is completed.

  Then, the event queue 35 supplies the supplied timeout event to the callback thread 34. Then, the callback thread 34 requests a callback process corresponding to the supplied timeout event from the application 40 (callback processing unit 41) (S404). Here, it is assumed that control for stopping reproduction of the audio file F1 is set in the application 40 (callback processing unit 41) as the next callback processing for the thread 31-1.

  Then, the application 40 (callback processing unit 41) instructs the API processing unit 32 to stop reproduction of the audio file F1 in accordance with the definition of the next callback processing (S405). Then, the API processing unit 32 stores the control instruction describing the content of the control instruction in the shared memory 36 (S406).

  Thereafter, the thread 31-1 is periodically activated, and the process of periodic activation B1351 (the processes of steps S407 to S409) is executed.

  In the periodic activation B1351, the thread 31-1 first confirms the contents of the shared memory 36, recognizes that the control instruction to itself is stored, and acquires the control instruction (S407).

  Then, the thread 31-1 performs a reproduction stop process for the audio file F1 based on the content of the acquired control instruction (S408). When the playback stop process for the audio file F1 is performed, the thread 31-1 notifies the event queue 33 of an event indicating that the playback stop process has been executed (S409). Thus, the process in the periodic activation B601 by the thread 31-1 is completed.

  Then, the event queue 33 notified of the reproduction process stop event holds the event and notifies the application 40 (S410).

(A-3) Effects of Embodiment According to this embodiment, the following effects can be achieved.

(A-3-1) In the data processing apparatus 1, since the timer processing using the counter of the timer processing unit 311 is executed on the thread 31 side, accurate reproduction timing control is possible.

  Further, the timer processing unit 311 of the thread 31 can perform the timer processing only by incrementing the counter for each period activation. That is, in the data processing apparatus 1, it is not necessary to implement processing related to timer processing on the application 40 side, and the processing load due to addition of timer processing hardly occurs.

(A-3-2) In the data processing device 1, a transmission path (callback thread 34 and event queue 35) dedicated to callback processing associated with a timer event from the thread 31 to the application 40 is set. As a result, the data processing apparatus 1 can quickly execute a callback process associated with a timeout event with a simple configuration. That is, the data processing apparatus 1 can efficiently execute a callback process associated with a timeout event.

  In the data processing device 1, the above-described transmission path dedicated to the callback process may be omitted, but in that case, the efficiency of the process similar to the callback process is lowered. For example, the thread 31 notifies the application 40 of the occurrence of a timeout event (for example, an event indicating that a timeout has occurred after the start of playback of the audio file) via the event queue 33, and the content of the event is indicated on the application 40 side. Analysis may be performed to determine the next process (for example, audio file playback stop process), and the thread 31 may be instructed via the API processing unit 32. However, in this case, since event analysis and determination processing in the application 40 are required, the transmission path related to the callback processing described above can execute the next processing at a high speed with a small processing amount. Become.

  When events other than the timeout event are also concentrated in the event queue 33, the event queue 33 may become a bottleneck and processing may be delayed. However, by providing a transmission path dedicated to the timeout event as in the data processing apparatus 1, the callback process associated with the timeout event can be quickly executed with a simple configuration. Further, the processing corresponding to the callback processing may be performed only within the media data processing unit 30, but the transmission path for calling back from the application 40 using the API has a configuration within the media data processing unit 30. Can be simple.

  In other words, in the data processing apparatus 1, the API 40 can be executed from the callback processing unit 41 by adding the callback thread 34, so that the application 40 can be easily implemented. In particular, when the media data processing unit 30 is realized as middleware, it is easy to upgrade the middleware (media data processing unit 30) without affecting the application 40.

(B) Other Embodiments The present invention is not limited to the above-described embodiments, and may include modified embodiments as exemplified below.

(B-1) In the above embodiment, in the data processing apparatus 1, the control of the playback timing of the audio file has been described as an example. However, it is used for other timing control (for example, the playback timing of a moving image). May be.

(B-2) In the above embodiment, the event queue 35 has been described as a queue dedicated to a timeout event. However, the event queue 33 and the event queue 35 may be allocated differently. For example, the event queue 33 may be omitted.

  In the above-described embodiment, the callback thread 34 is described as one configuration, but a plurality of callback threads 34 may be provided.

(B-3) In the above embodiment, the example in which the media data processing unit 30, the application 40, and the signaling processing unit 50 are constructed on the same computer has been described. However, the media data processing unit 30, the application 40, and the signaling processing unit 50 may be constructed on different computers. Good. That is, the configuration of the distributed processing when constructing the data processing device 1 is not limited.

  DESCRIPTION OF SYMBOLS 1 ... Data processing apparatus, 10 ... Hardware, 20 ... General purpose OS, 30 ... Media data processing part, 31 ... Thread, 311 ... Timer processing part, 31, 31-1 to 31-N ... Thread, 32 ... API processing part 33 ... Event queue 34 ... Callback thread 35 ... Event queue 36 ... Shared memory 40 ... Application 41 ... Callback processing unit 50 ... Signaling processing unit

Claims (4)

Media data processing means for processing media data using threads according to the control of the application processing means,
The above thread
Data processing means that periodically starts and performs processing related to media data;
Timer means for measuring time using a counter to which a counter value is added each time the data processing means is activated,
The data processing apparatus, wherein the data processing means performs time measurement related to processing performed by the data processing means using the timer means under the control of the application processing means. The data processing means, when instructed by the application processing means to measure the processing time related to media data processing, causes the timer means to execute the time measurement using the processing time as a timeout time, and the timer means Output a timeout event when a timeout occurs in
The media data processing unit
A first event processing unit that processes only a timeout event that has occurred in each thread;
The data processing apparatus according to claim 1, further comprising: a second event processing unit that processes an event other than a timeout event that has occurred in each thread.   The media data processing unit further includes a callback request processing unit for requesting the application processing unit to perform predetermined processing on a thread related to the timeout event when the first event processing unit holds the timeout event. The data processing apparatus according to claim 2, further comprising: Computer
According to the control of the application processing means, function as media data processing means for processing media data using threads,
The above thread
Data processing means that periodically starts and performs processing related to media data;
Timer means for measuring time using a counter to which a counter value is added each time the data processing means is activated,
A data processing program characterized in that the data processing means uses the timer means to perform time measurement related to processing performed by the data processing means under the control of the application processing means.

Images