KR100736568B1 - Mobile communication terminal and method for playing sound using a2dp - Google Patents

Abstract

A mobile communication terminal and a method for regenerating a sound source by using an A2DP(Advanced Audio Distribution Profile) are provided to reduce cost in transplanting a platform by additionally defining a scheme used when a midlet developer and a JAVA platform transplanting developer generate a JAVA player. A mobile communication terminal comprises a controller(110), an inputting unit(120), a display unit(130), a memory(140), an audio outputting unit(150), a midlet processor(160) and a bluetooth module(170). The controller(110) controls function implemented in the mobile communication terminal, and processes other components, data and signals. The inputting unit(120), composed of digit buttons, special key buttons, character key buttons, and function key buttons, operates as an interface for transmitting user's instructions to the controller(110). The display unit(130), composed of a display device like an LCD or an OLED(Organic Light Emitting Diode), displays a menu screen for enabling a user to select a menu, an executed screen in accordance with the selection of the menu, and a result screen. The memory(140), composed of a flash memory, an RAM or an EEPROM, stores music files. The audio outputting unit(150) converts the music files, stored at the memory(140), into audible sound via a speaker according to a control operation of the controller(110). The midlet processor(160) plays a role of setting a reproduction path of the music file when the music file is reproduced. The bluetooth module(170) exchanges control signals with or transmits the music file to a headset.

Description

Mobile communication terminal and method for playing sound using A2DP}

1 is a system configuration diagram for wirelessly reproducing sound according to an embodiment of the present invention.

2 is a conceptual diagram illustrating a platform structure of the mobile communication terminal shown in FIG. 1.

3 is a flowchart illustrating a procedure for porting a platform according to an embodiment of the present invention.

4 is a diagram illustrating a code template of a middlelet according to an embodiment of the present invention.

5 is a view showing a path for playing the sound source to the Bluetooth headset according to an embodiment of the present invention.

6 is a diagram illustrating a path for reproducing a sound source in a terminal according to an embodiment of the present invention.

7 is a verification code for verifying whether a code template of a middlelet is used in a terminal according to an embodiment of the present invention.

The present invention relates to a mobile communication terminal, and more particularly, to a mobile communication terminal and a sound reproduction method using A2DP for reproducing Java application music on a Java platform.

To play media in Java application development (MIDlet), you need to create a Player with createPlayer (). There are two ways to create a Player using media_locator, DataSource, and InputStream. In particular, when media is played using A2DP, it is not defined in JSR-135 MMAPI. Therefore, it has to be developed in the existing way by using one of the three methods above. A2DP is an Advanced Audio Distribution Profile, which is a profile required to listen to radio by applying Bluetooth technology to sound sources such as mp3.

However, in order to support the A2DP function in the terminal, the Bluetooth module of the terminal must decode each sound source. In other words, when the decoder of the Bluetooth module does not support all the sound sources, developers who port the Java platform have to consider all the cases to solve the problem.

In addition, A2DP using Bluetooth has a lot of dependence on the hardware specification of the mobile communication terminal, which increases development time. As a result, if the hardware changes, maintenance must be performed accordingly, which increases the cost.

In order to solve this problem, the present invention provides a sound source using a mobile communication terminal and A2DP to improve the performance and quality of terminal development by dividing Java applications and platforms without compromising Java platform independence and flexibility. Its purpose is to provide a regeneration method.

In order to achieve the above object, the present invention provides an input unit for selecting a media file to be played, a middlelet processing unit for checking whether a parameter for playing the media file is a predefined specific parameter, and, if the specific parameter corresponds to an external playback device, Provided is a mobile communication terminal including a transmission unit for transmitting a media file.

At this time, if the external communication device is not connected to the mobile communication terminal, the parameter is file: // scheme, and further includes an audio output unit for playing the media file in the terminal.

In addition, the media file may further include an output unit for displaying an error if the media file is not a playable media type.

The apparatus may further include a memory unit for storing the media file, wherein the middlelet processor is in the form of a MIDlet.

Here, the specific parameter uses A2DP (Advanced Audio Distribution Profile), and when A2DP: // scheme, the transmitter is a Bluetooth module.

On the other hand, the present invention comprises the steps of selecting a media file to play, confirming whether a parameter for playing the media file is a predefined specific parameter, and if the specific parameter, the media file is transmitted to the external playback device It provides a sound source playback method using the A2DP comprising a step.

In addition, the specific parameter checking step may further include determining whether an external playback device for playing the media file is connected, and if connected, checking whether the parameter is a predetermined specific parameter. Do.

On the other hand, if the external playback device is not connected, the parameter is file: // scheme, and the media file is played back in the terminal itself.

Here, the specific parameter may be A2DP: // scheme using A2DP (Advanced Audio Distribution Profile).

In this case, the media file may be a music file or a video file.

Therefore, according to the present invention, the cost of platform transplantation can be reduced by additionally defining a scheme used when generating a Java player between a middlelet developer and a Java platform transplant developer. In addition, it can be implemented to distinguish whether the Java player uses the A2DP function, there is an advantage that can be processed in advance when running the middlelet on the terminal.

Hereinafter, with reference to the accompanying drawings will be described in detail an embodiment according to the present invention.

1 is a system configuration diagram for wirelessly reproducing sound according to an embodiment of the present invention. Referring to FIG. 1, the system configuration includes a mobile communication terminal 100 that processes and transmits a sound source wirelessly, and a headset 10 that reproduces the transmitted sound source.

The mobile communication terminal 100 processes the sound source and wirelessly transmits the sound source to the headset 10 or plays it on its own without transmitting to the headset 10. The mobile communication terminal 100 controls the control unit 110, the input unit 120, the display unit 130, the memory unit 140, the audio output unit 150, the middlelet processing unit 160, and the Bluetooth module unit 170. Include.

The controller 110 controls a function implemented in the mobile communication terminal 100 and processes data and signals with other components.

The input unit 120 is a digit button (0-9) and a special key button (*, # ....) used as an input from the mobile communication terminal 100, a letter key button engraved with the Korean alphabet or alphabet, functions Consists of a function key button to perform an interface role of transmitting a user's instruction to the control unit 110. Of course, in one embodiment of the present invention it is also possible to configure a specific key button for selecting the sound source playback.

The display unit 130 may be formed of a display device such as a liquid crystal display (LCD), an organic light emitting diode (OLED), and the like, and may be controlled by the user of the mobile terminal according to the control of the controller 110. Displays the selected menu screen, the execution screen, and the result screen. In particular, in one embodiment of the present invention, a menu screen for selecting a sound source playback function and selecting a corresponding song may be configured.

The memory unit 140 may be configured of a flash memory, a RAM, an electrically erasable programmable read only memory (EEPROM), and the like. In particular, in one embodiment of the present invention stores the music file 141. Of course, the music file is not only stored in the memory unit 140 but also can be downloaded through the wireless Internet, it is also possible to receive from a storage device such as a USB memory (Universal Serial Bus Memory Stick).

The audio output unit 150 converts the music file 141 stored in the memory unit 140 into an audible sound through a speaker 151 under the control of the controller 110. Of course, it is also possible to modulate the voice signal received from the microphone (Mic) 152, convert it into digital voice data, and transmit it to the controller 110.

When the music file 141 is played, the middlelet processing unit 160 plays a role of designating a playback path of the music file 141. That is, when the headset 10 is connected, the music file is wirelessly transmitted to the headset 10 using Bluetooth. In contrast, when the headset 10 is not connected, the music file 141 is processed in the terminal itself.

The Bluetooth module unit 170 exchanges a control signal with the headset 10 and transmits a music file 141 by using Bluetooth.

The headset 10 for receiving and playing the music file 141 from the mobile communication terminal 100 exchanges a control signal with the Bluetooth module 170 and receives the music file 141. And a microcomputer 12 for controlling the headset 10, a codec unit 13 for coding a music file 141, and a headset speaker 15 for outputting a coded sound source.

The headset Bluetooth module unit 11 is a module for realizing a Bluetooth wireless connection, and exchanges a control signal with the Bluetooth module unit 170 of the mobile communication terminal 100 and receives a music file 141 and the like.

The microcomputer 12 controls the headset 10 and exchanges signals and data with other components. The storage unit 14 is composed of a flash memory, a RAM, an electrically erasable programmable read only memory (EEPROM), and the like to temporarily store the music file 141.

The music file 141 transmitted through the headset Bluetooth module unit 11 is played through the codec unit 13. To this end, the codec unit 13 is composed of a coder / decoder and performs a codec process. do. Through this codec process, the sound source is converted into analog audio and reproduced as music sound through the headset speaker 15.

2 is a conceptual diagram illustrating a platform structure of the mobile communication terminal shown in FIG. 1. Referring to FIG. 2, the MIDlet 210 is an application that operates on a Mobile Information Device Profile (MIDP). Usually, Java Application Manager (JAM) installs, manages, and operates the MIDlet 210. JAM is a Java Application Manager that manages applications on the CLDC / MIDP platform.

In addition, in order for the MIDlet 210 to operate, a layer such as a MIDP, a connected limited device configuration (CLDC), an OEM class, and the like are placed. In brief, the MIDP is a profile created for a specific device in the CLDC and mainly consists of a terminal (user interface) of the terminal. CLDC, of course, defines a basic set of application programming interfaces. The OEM class is a separate class that makes MIDlets available for support that is not included in the Java specification.

The JVM 220 is a virtual machine (Java Virtual Machine), and performs a function of driving Java in the mobile communication terminal. Therefore, it is system software that executes class files with compiled Java executable code. That is, software that acts as an interface between binary code and a microprocessor (or hardware platform).

Therefore, the JVM 220 transmits a command executed by the MIDlet 210 to the system OS 240 using the porting layer 230. At this time, the porting layer 230 plays the music file 141 with the headset 10 or the speaker 151 according to the command of the middlelet 210. Of course, for this purpose, the system OS 240 has an OS used for the terminal and various device libraries. Such native OSs include programs such as Symian, Rex, and EOS.

3 is a flowchart illustrating a procedure for porting a platform according to an embodiment of the present invention. Referring to FIG. 3, a supportable type for the A2DP protocol is first defined (step S310). That is, it defines the supported media types (mp3, wav, midi, aac, etc.).

If the media type that can be supported is defined, the playback method that can be supported for the A2DP protocol is defined (step S320). That is, a playback method such as buffer play, file play, streaming play, etc. is defined.

Therefore, when the "file: //" scheme is used, media types such as mp3, aac, wav, and midi can be played, and a file play can be performed as a playback method. Here, Scheme means a path for playing a media file as a protocol. In other words, if the "file: //" scheme is used, the terminal plays the media file.

In contrast, when the "A2DP: //" scheme is used, media types such as mp3, aac, wav, and midi can be played, and the playback method is buffer play, file play, and streaming play.

If the playback method is defined, there is a process of checking whether the headset 10 shown in FIG. 1 supporting Bluetooth is connected (step S330). The reason why this process is necessary is to allow music files to be played in the terminal 100 shown in FIG. 1 when the headset 10 is not connected.

Therefore, if the headset 10 is connected, it is checked whether the playback path is the A2DP scheme (step S340). That is, if the parameter used when creating the Java player was "A2DP: //", this means that the sound source will be played through the Bluetooth-enabled headset. Of course, no sound is reproduced unless it is an A2DP scheme (step S341).

If it is the A2DP scheme, it is checked whether the music file to be played is a music file that can be supported (step S350). That is, the supportable media type described above is defined, which is a process of checking whether the music file to be played corresponds to the defined media type.

For example, if the defined media types are mp3, aac (Advanced Audio Coding), 3gpp (3rd Generation Partnership Project), if the music file to be played is mp3 type, it is played through Bluetooth (step S360). That is, playback is performed with the headset 10 shown in FIG.

On the other hand, if the music file to be played is OGG (Ogg Vorbis) type, this is an unsupported media type. In this case, an error message is displayed so that the user can know that the media file is not supported (step S351). This error message could be "unsupported media file".

On the other hand, if the headset 10 shown in Fig. 1 is not connected, it is checked whether the playback path is a file scheme (step S370). In other words, if the headset 10 is not connected, it means that the playback path of the music file to be played is a file scheme. At this time, the parameter is "File: //".

As a result of checking the file scheme, if the playback path is a file scheme, music files are played (step S371). In contrast, if the reproduction path is the A2DP scheme, reproduction of the music file is not performed (step S372).

Here, the music file to be played is a media type and can be a video file besides an audio file. Therefore, it is possible to display an error in the case of a video file. Alternatively, you can play the sound without playing the screen.

4 is a diagram illustrating a code template of a middlelet according to an embodiment of the present invention. That is, the MIDlet 210 illustrated in FIG. 2 is a diagram showing a code of a Java application of the MIDlet 210 developed according to the platform transplantation procedure described in FIG. 3 as an application layer. Referring to Fig. 4, "boolean bA2DP = com.OEMAPI.isConnectedBT ();" is a Boolean function, which is a function for checking whether the headset 10 shown in Fig. 1 is connected or not.

Therefore, if the headset 10 is connected, the A2DP scheme is used. That is, "if (bA2DP) {p = Manager.createPlayer (" A2DP: // File_URI ");".

On the contrary, if the headset 10 is not connected, a general pile scheme is used. That is, "else {p = Manager.createPlayer (" file: // File_URI "); where" A2DP: // "and" file: // "represent the scheme, and" File_URI "is shown in FIG. The storage location of the music file 141 stored in the memory unit 140 is shown.

If either the "A2DP: //" or "file: //" scheme is specified, the music file is played via realize () → prefetch () → start () according to the JSR-135 MMAPI specification.

Next, FIGS. 5 and 6 are diagrams illustrating a path in which a music file is played by FIGS. 3 and 4. 5 illustrates a path for reproducing a sound source with a Bluetooth headset according to an embodiment of the present invention. That is, the playback path is a music file (MP3; 500) → MIDlet 210 → JVM 220 → porting layer 230 → system OS 240 → headset 10. Of course, the system OS 240 and the headset 10 are shown in solid lines, but since the headset 10 supports Bluetooth, data is wirelessly transmitted.

6 is a diagram illustrating a path for reproducing a sound source in a terminal according to an embodiment of the present invention. In other words, when the headset 10 is not connected, a path for playing music files in the terminal is illustrated. At this time, the playback path is a music file (MIDI) 600 → MIDlet 210 → JVM 220 → porting layer 230 → system OS 240 → speaker 151.

7 is a verification code for verifying whether a code template of a middlelet is used in a terminal according to an embodiment of the present invention. That is, the source code for checking whether the terminal uses the "A2DP: //" scheme. Therefore, if the terminal is using "A2DP: //", the message is "Used", and if not, it is "Not used". The code for this is:

if (bA2DP) {// Show alert to user "Used"

} else {

// Show alert to user "Not used"

}

As mentioned above, although this invention was demonstrated in detail using the preferable Example, the scope of the present invention is not limited to a specific Example, If the person who acquired the ordinary knowledge in this technical field, without departing from the range of this invention, It should be understood that many modifications and variations are possible. Therefore, the protection scope of the present invention will be preferably interpreted by the appended claims.

As described above, according to the present invention, the cost of platform transplantation can be reduced by additionally defining a scheme used when generating a Java player between a middlelet developer and a Java platform transplant developer.

In addition, it can be implemented to distinguish whether the Java player uses the A2DP function, there is an advantage that can be processed in advance when running the middlelet on the terminal.

Claims (13)

Selecting a media file to play; Checking whether a parameter for playing the media file is a predetermined specific parameter; And transmitting the media file to an external playback device if the specific parameter corresponds. The method of claim 1, Checking whether the specific parameter is, Determining whether an external playback device for playing the media file is connected; If connected, checking whether the parameter is a predefined specific parameter. The method of claim 2, If the external playback device is not connected, the parameter is a file: // scheme, and the media file is played back in the terminal itself. The method of claim 1, And the specific parameter is A2DP: // scheme using A2DP (Advanced Audio Distribution Profile). The method of claim 1, And the media file is a music file or a video file. An input unit for selecting a media file to be played; A middlelet processing unit which checks whether a parameter for playing the media file is a predetermined specific parameter; And a transmission unit for transmitting the media file to an external playback device if the specific parameter corresponds. The method of claim 6, If the external playback device is not connected, the parameter is file: // scheme, and further includes an audio output unit for playing the media file in the terminal. The method of claim 6, And an output unit for displaying an error if the media file is not a playable media type. The method of claim 6, And a memory unit for storing the media file. The method of claim 6, The specific parameter is A2DP (Scheme) using the Advanced Audio Distribution Profile (A2DP). The method of claim 6, The middlelet processing unit is operated by MIDlet software. The method of claim 6, And the media file is a music file or a video file. The method of claim 6, The transmitter is a mobile communication terminal, characterized in that the Bluetooth module.

Images