The present invention relates to the field of electronic circuits and more specifically to a process of audio data exchange between a central processing unit and a wireless communication Bluetooth controller.
Wireless communication tend to be generalized in the apparatuses forming part of our everyday life, and these are in particular the apparatuses and devices designed for the public.
In this respect, the wireless communication protocol known as BLUETOOTH is particularly illustrative and its use has been grown quickly.
An essential quality of an audio reader, such as an mp3 reader for example, lies in the operation life of its battery. The high number of necessary functionalities required in the most recent devices, in which, one multiplies at will the applications such as the mobile telephony, the electronic agendas and organizers and the color screens, obviously results in reducing the lifespan of the battery, which reduction is a major problem.
It is thus desirable to envisage solutions permitting to reduce the electricity consumption of a sophisticated audio reader using a wireless bluetooth connection, as much as possible.
The object of the present invention is to propose an exchange process between a central processing unit and a bluetooth controller ensuring the possibility of a constant reading of audio files (streaming) while allowing a succession of idle and operation periods of the central processing unit in order to reduce electricity consumption.
Another object of this invention consists in proposing a process allowing the to communication of a continuous audio stream (streaming) towards a wireless audio headset according to Bluetooth technology, since a bluetooth communication controller, intermittently communicating with a central processing unit, alternating between idle phases and operation phases.
A third object of the present invention consists in producing a mobile phone or a Personal Document Assistant equipped with audio functionalities and exchanging with an audio headset according to a wireless technology, and allowing a longer battery lifespan.
These objects are achieved by the invention, by means of an electronic device comprising audio/video functionalities including:
characterized in that it comprises
In an embodiment, the central processing unit comprises means for transmitting a A2DP_enable request to the controller, defining a threshold value (T1) for the buffer, before transmitting a packets burst of audio/video files.
Preferably, the communication controller answers to said request defining the threshold value (T1) by a command specifying the number N of packets being able to be received and stored in said buffer.
In an embodiment, the central processing unit proceeds to the successive transmission of N packets before its setting in idle state during a predetermined period.
The invention is particularly adapted to the production of a mobile phone comprising audio/video functionalities.
The invention also allows the achievement of a process of data exchange between a central processing unit comprising means of storage of audio/video files and a Bluetooth communication controller allowing the wireless communication of audio/video files towards a satellite, such as a wireless headset for example, said communication controller comprising a buffer (210) ensuring the provisional storage of audio/video data received by the central processing unit.
The process comprises the following steps:
In a particular embodiment, the controller transmits a UART_WAKE request when the level of filling said buffer passes below said threshold value (T1).
Other characteristics, objects and advantages of the invention will appear by the reading of the description and the drawings hereafter, given only as non limitative examples. On the annexed drawings:
The invention is particularly adapted to the production of a last generation mobile phone comprising wide audio functionalities allowing the transmission of audio stream on coder-decoders (Codec) or on a wireless headset corresponding to to the Bluetooth standard.
According to
Typically, the central processing unit is structured around an appropriate processor 110, communicating via an address and data bus 101 with one or a plurality of input/output units 120, like with Read Access Memory 130 and storage memory 140, such as ROM (Read Only Memory), EPROM (Erasable Programmable Read Only Memory or FLASH etc. . . . ). Generally, the storage memory is used for storage of the users files, in particular the audio files of mp3 format, but it is also used for the storage of microprograms instructions in particular for implementing the advanced functionalities of the device 10. In the case of a mobile phone, the central processing unit 100 further comprises the reception and transmission circuits likely to allow a wireless communication in accordance with a given standard.
In addition, the portable device 10 comprises a bluetooth controller 200 intended to manage a wireless communication according to the Bluetooth protocol and in particular for an audio data transmission with a distant satellite 20, such that of a wireless headset for example. The audio data received in continuous stream (streaming) is encapsulated, as it is known, in a A2DP (Advanced Audio Distribution Profile).
The Bluetooth controller 20 comprises its own processor (not represented) and its accessory circuits allowing the transfer of audio data in continuous mode (streaming) with the satellite unit 30 or the wireless headset, as well as with a buffer 210 (FIFO).
The communication between the central processing unit (host) 100 and the bluetooth communication controller is performed by means of a UART (Universal Asynchronous Receiver Transmitter) standard interface.
The problem results from the fact that, when all the circuits of the central processing unit 100 are active, the latter consume a high level of current thus reducing the battery life.
In order to reduce the current consumption, one envisages to modify the Bluetooth communication controller 200 so as to incorporate in the latter the management software layer of A2DP profile which is, usually and according to normative recommendations, integrated into the level of the central processing unit 100.
Thus, the controller 200 becomes autonomous and can only manage communication of an audio data stream (streaming) towards the satellite 20.
Generally, the A2DP profile is well-known to a man skilled in the art and will not be further detailed.
The delocalization in the Bluetooth controller 200 is based on the API definition allowing the initialization and the configuration of the A2DP profile normally carried out in the central processing unit (host).
One describes now, in relation to
In a step 1, the central processing unit is configured in a “A2DP burst” mode and defines a variable of threshold T1.
Then, in a step 2, the central processing unit transmits a specific command HCI (Host Control Interface), comprising the value of the variable of threshold T1, and informing the controller 200 of the activation of the “A2DP_burst” mode. In a practical manner, this command is carried out by means of a specific code is standardized in the Bluetooth specification (0x3F).
Then, in a step 3, the communication controller 200 stores in its built-in memory the threshold value T1 and is configured in a “A2DP_burst” mode in order to receive, in an intermittent way, packets or chunks of data stream.
In a step 4, the controller transmits a confirmation message to the central processing unit 100, also confirming the number N of packets which can be received and stored within the buffer. Then, the controller initializes the buffer 210.
In a step 5, the central processing unit transmits, in a sequential manner, the N packets (chunks) of audio data which then are successively stored within the centre of the buffer 210 of the controller 200.
Then, in a step 6, the central processing unit is set in a idle mode, thus limiting the electronic consumption during one predetermined period corresponding to the time of memory dump of the buffer (FIFO) 210.
On its side, the controller 200 in a step 7 detects the reception of packets received from the central processing unit, typically until the complete filling of the buffer.
Then, in a step 8, the controller 200 proceeds to the encapsulation of packets according to the Bluetooth protocol and to its emission with destination to satellite 20 or to the wireless headset. In addition, the controller monitors the level of filling of buffer 210.
In a step 9, the controller 200 detects the decrease of the filling of the buffer 210, and specifically the fact that the level passes under the threshold value T1 which, as mentioned above, is predetermined and fixed by the central processing unit 100. It proceeds to the transmission of a so-called UART_WAKE request intended for controlling the wake-up of the re-activation of the central processing unit.
This command, indicated as UART_WAKE, can be embodied in multiple forms according to the particular implementation for the mobile phone . . . .
In an example, one can be be based on the Bluetooth standard which gives the possibility of transmitting “owners” messages (i.e specifically chosen by the manufacturer) to the central processing unit in order to command its activation. One will be able to advantageously use a reserved code such as 0xFF.
Alternatively, according to the implementation, one will be able to hold a particular physical circuit or a particular logical channel in order to convey the specific UART_WAKE command intended to the activation of the central processing unit.
In a step 10, the central processing unit 100 proceeds to the exit of idle state and to the reactivation of its internal circuits. Consequently, it can confirm the appropriate reception of the UART_WAKE request.
Then, in a step 11, the central processing unit 100 can proceed to the reiteration of the preceding stages in order to carry out the transmission of a new data burst destined for the Bluetooth controller 200, before a new setting in an idle state, etc. . . .
As it is seen, this mechanism makes it possible to carry out an uninterrupted reading of an audio stream, for example of mp3 type, while significantly reducing the electricity consumption of the central processing unit.
The embodiment which has just been described is perfectly adapted to the streaming reading of audio files, but also video files.
Number | Date | Country | Kind |
---|---|---|---|
09 01173 | Mar 2009 | FR | national |
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/EP2010/001589 | 3/12/2010 | WO | 00 | 9/20/2011 |
Publishing Document | Publishing Date | Country | Kind |
---|---|---|---|
WO2010/102836 | 9/16/2010 | WO | A |
Number | Name | Date | Kind |
---|---|---|---|
6289464 | Wecker et al. | Sep 2001 | B1 |
8170624 | Huang et al. | May 2012 | B1 |
20030041199 | Kume et al. | Feb 2003 | A1 |
20030186715 | McGowan | Oct 2003 | A1 |
20050100116 | Mason | May 2005 | A1 |
20050136833 | Emeott et al. | Jun 2005 | A1 |
20060019686 | Rush et al. | Jan 2006 | A1 |
20060199621 | Stirbu et al. | Sep 2006 | A1 |
20060240798 | Jarosinski et al. | Oct 2006 | A1 |
20080125037 | Ibrahim et al. | May 2008 | A1 |
20080165829 | Lee et al. | Jul 2008 | A1 |
Number | Date | Country |
---|---|---|
1453212 | Sep 2004 | EP |
1701484 | Sep 2006 | EP |
1708410 | Oct 2006 | EP |
Entry |
---|
International Search Report for PCT/EP2010/001589 mailed Jun. 15, 2010. |
Written Opinion for PCT/EP2010/001589 mailed Jun. 15, 2010. |
Number | Date | Country | |
---|---|---|---|
20120009876 A1 | Jan 2012 | US |