<tdclass="cellrowborder"valign="top"width="50%"headers="mcps1.2.3.1.2 "><pid="p1596200459"><aname="p1596200459"></a><aname="p1596200459"></a>Audio streams for media purpose</p>
</td>
...
...
@@ -154,6 +160,11 @@ You use audio management APIs to set and obtain volume, and get information abou
<tdclass="cellrowborder"valign="top"width="50%"headers="mcps1.2.3.1.2 "><pid="p9333131144712"><aname="p9333131144712"></a><aname="p9333131144712"></a>Audio streams for ring tones</p>
<tdclass="cellrowborder"valign="top"width="50%"headers="mcps1.2.3.1.2 "><pid="p538905016496"><aname="p538905016496"></a><aname="p538905016496"></a>Bluetooth device using the synchronous connection oriented link (SCO)</p>
<tdclass="cellrowborder"valign="top"width="50%"headers="mcps1.2.3.1.2 "><pid="p538905016496"><aname="p538905016496"></a><aname="p538905016496"></a>Bluetooth device using the synchronous connection oriented (SCO) link</p>
<tdclass="cellrowborder"valign="top"width="50%"headers="mcps1.2.3.1.2 "><pid="p193891550134912"><aname="p193891550134912"></a><aname="p193891550134912"></a>Bluetooth device using advanced audio distribution profile (A2DP)</p>
4. Call the **start()** function on the AudioRenderer instance to start/resume the playback task.\
The renderer state will be STATE_RUNNING once the start is complete. You can then begin writing buffers.
The renderer state will be STATE_RUNNING once the start is complete. You can then begin writing buffers.
```
asyncfunctionstartRenderer(){
varstate=audioRenderer.state;
...
...
@@ -148,13 +144,14 @@ Here's an example of how to use AudioRenderer to play a raw audio file.
console.info('Renderer is not in a correct state to start');
return;
}
varstarted=awaitaudioRenderer.start();
if(started){
isPlay=true;
awaitaudioRenderer.start();
state=audioRenderer.state;
if(state==audio.AudioState.STATE_RUNNING){
console.info('Renderer started');
}else{
console.error('Renderer start failed');
return;
}
}
...
...
@@ -212,8 +209,11 @@ Here's an example of how to use AudioRenderer to play a raw audio file.
console.info('Renderer is not running');
return;
}
varpaused=awaitaudioRenderer.pause();
if(paused){
awaitaudioRenderer.pause();
state=audioRenderer.state;
if(state==audio.AudioState.STATE_PAUSED){
console.info('Renderer paused');
}else{
console.error('Renderer pause failed');
...
...
@@ -226,8 +226,11 @@ Here's an example of how to use AudioRenderer to play a raw audio file.
console.info('Renderer is not running or paused');
return;
}
varstopped=awaitaudioRenderer.stop();
if(stopped){
awaitaudioRenderer.stop();
state=audioRenderer.state;
if(state==audio.AudioState.STATE_STOPPED){
console.info('Renderer stopped');
}else{
console.error('Renderer stop failed');
...
...
@@ -243,8 +246,11 @@ Here's an example of how to use AudioRenderer to play a raw audio file.
console.info('Resourced already released');
return;
}
varreleased=awaitaudioRenderer.release();
if(released){
awaitaudioRenderer.release();
state=audioRenderer.state;
if(state==STATE_RELEASED){
console.info('Renderer released');
}else{
console.info('Renderer release failed');
...
...
@@ -257,7 +263,6 @@ Here's an example of how to use AudioRenderer to play a raw audio file.
You should also keep in mind that an AudioRenderer is state-based.
That is, the AudioRenderer has an internal state that you must always check when calling playback control APIs, because some operations are only acceptable while the renderer is in a given state.\
The system may throw an error/exception or generate other undefined behaviour if you perform an operation while in the improper state.\
Before each necessary operation, the example code performs a state check.
## **Asynchronous Operations:**
Most of the AudioRenderer calls are asynchronous. As a result, the UI thread will not be blocked.\
...
...
@@ -267,4 +272,3 @@ provides reference for both callback and promise.
## **Other APIs:**
See [**js-apis-audio.md**](https://gitee.com/openharmony/docs/blob/master/en/application-dev/reference/apis/js-apis-audio.md) for more useful APIs like getAudioTime, drain, and getBufferSize.
<tdclass="cellrowborder"valign="top"width="59.67%"headers="mcps1.1.4.1.3 "><pid="p182452299212"><aname="p182452299212"></a><aname="p182452299212"></a>Audio stream for media purpose.</p>
<tdclass="cellrowborder"valign="top"width="59.67%"headers="mcps1.1.4.1.3 "><pid="p193351683289"><aname="p193351683289"></a><aname="p193351683289"></a>Bluetooth device using the synchronous connection oriented (SCO) link.</p>
<tdclass="cellrowborder"valign="top"width="59.67%"headers="mcps1.1.4.1.3 "><pid="p549117620284"><aname="p549117620284"></a><aname="p549117620284"></a>Bluetooth device using the advanced audio distribution profile (A2DP).</p>
The Inter-Integrated Circuit \(I2C\) bus is a simple and bidirectional two-wire synchronous serial bus developed by Philips. In the Hardware Driver Foundation (HDF) framework, the I2C module uses the unified service mode for API adaptation. In this mode, a device service is used as the I2C manager to handle external access requests in a unified manner, which is reflected in the configuration file. The unified service mode applies to the scenario where there are many device objects of the same type, for example, when the I2C module has more than 10 controllers. If the independent service mode is used, more device nodes need to be configured and memory resources will be consumed by services.
**Figure 1** Unified service mode<aname="fig17640124912440"></a>
In the Hardware Driver Foundation \(HDF\) framework, the Pulse Width Modulator \(PWM\) uses the independent service mode for API adaptation. In this mode, each device independently publishes a device service to handle external access requests. After receiving an access request from an API, the device manager extracts the parameters in the request to call the internal method of the target device. In the independent service mode, the service management capabilities of the HDF Device Manager can be directly used. However, you need to configure a device node for each device, which increases the memory usage.
**Figure 1** Independent service mode<aname="fig983655084219"></a>
In the Hardware Driver Foundation \(HDF\) framework, the real-time clock \(RTC\) uses the independent service mode for API adaptation. In this mode, each device independently publishes a device service to handle external access requests. After receiving an access request from an API, the device manager extracts the parameters in the request to call the internal method of the target device. In the independent service mode, the service management capabilities of the HDFDeviceManager can be directly used. However, you need to configure a device node for each device, which increases the memory usage.
**Figure 1** Independent service mode<aname="fig6742142611299"></a>
A Secure Digital Input Output \(SDIO\) card is an extension of the SD specification to cover I/O functions. SD and SDIO are called multimedia card \(MMCs\). In the Hardware Driver Foundation \(HDF\) framework, the SDIO module uses the independent service mode for API adaptation. In this mode, each device independently publishes a device service to handle external access requests. After receiving an access request from an API, the device manager extracts the parameters in the request to call the internal method of the target device. In the independent service mode, the service management capabilities of the HDFDeviceManager can be directly used. However, you need to configure a device node for each device, which increases the memory usage.
**Figure 1** Independent service mode<aname="fig124181331222"></a>
In the Hardware Driver Foundation \(HDF\) framework, the Universal Asynchronous Receiver/Transmitter \(UART\) uses the independent service mode for API adaptation. In this mode, each device independently publishes a device service to handle external access requests. After receiving an access request from an API, the device manager extracts the parameters in the request to call the internal method of the target device. In the independent service mode, the service management capabilities of the HDF Device Manager can be directly used. However, you need to configure a device node for each device, which increases the memory usage.
**Figure 1** Independent service mode<aname="fig1474518243468"></a>
In the Hardware Driver Foundation \(HDF\) framework, the Watchdog \(also called Watchdog timer\) module uses the independent service mode for API adaptation. In this mode, each device independently publishes a device service to handle external access requests. After receiving an access request from an API, the device manager extracts the parameters in the request to call the internal method of the target device. In the independent service mode, the service management capabilities of the HDF Device Manager can be directly used. However, you need to configure a device node for each device, which increases the memory usage.
**Figure 1** Independent service mode<aname="fig61584136211"></a>
When **DRIVERS\_WLAN\_XXX** is enabled in the kernel, **makefile** in **//device/MySoCVendor/peripheral/build/standard/** is called. For more details, see [WLAN Development](../guide/device-wlan-led-outcontrol.md).
When **DRIVERS\_WLAN\_XXX** is enabled in the kernel, **makefile** in **//device/MySoCVendor/peripheral/build/standard/** is called. For more details, see [WLAN Development](../guide/device-wlan-led-control.md).
