4.6 Stream Management
4.6.7 Synchronization
There are three different domains in which synchronization of streams is desired. They are multiple streams on different systems, multiple streams on different controllers in the same system, and multiple streams on the same controller.
The Intel® High Definition Audio Specification does not provide any mechanisms to aid in synchronizing streams on two different systems but does provide mechanisms to synchronize streams within a system. The wall clock can be used to synchronize between two separate controllers which do not share a common clock, and the stream start synchronization can be used to synchronize exactly two streams on the same controller.
Intel® High Definition Audio Programming Model
4.6.7.1
Controller-to-Controller Synchronization
The Intel® High Definition Audio Specification requires that the controller provide a ‘wall’ clock, implemented in the Global Synchronization and Control Register, which is a monotonically increasing 32 bit counter. Whenever bit clock is running, this clock is also running. This time base may be used to account for drift between two different audio subsystems by performing micro- sample rate conversion operations on the audio data to keep the drift between streams running on the independent controllers to within a specified error.
4.6.7.2
Stream-to-Stream Start Synchronization
Using the SSYNC bits in combination with the stream RUN bits, multiple input and streams can be synchronized in time.
When the hardware is initialized, all the relevant stream descriptor’s RUN bits are cleared. Also, the relevant SSYNC bits are cleared as well. To synchronously start a set of streams, software will set the relevant SSYNC bits to 1 to indicate the set of streams to be synchronously started and then set the stream’s RUN bit to cause the DMA engine to fetch data. While the SSYNC bits are set, though, data will not be sent on to the link, essentially leaving the stream in a “pause” state. Software then must wait until each output stream’s FIFORDY bit is set, indicating that the DMA engines have fetched enough data to start the stream in the case of an output stream, or fetched enough buffer descriptors to have a place to put the incoming data in the case of an input stream. This ensures that all output streams will have sufficient data ready, or a place to put it, when the streams are started. Note that for input streams, FIFORDY is set to 1 as a function of whether one or more Input-Descriptors are available in the Input Stream buffer, independent of the descriptor’s length value. If the first descriptor-length value is very small, it increases the likelihood that overrun condition will occur.
When all relevant FIFORDY bits are set, software clears the relevant SSYNC bits using a single write to the Stream Synchronization register causing the streams to begin flowing. All output streams will transmit their first sample on the link frame following the de-assertion of their SSYNC bit, and input streams will capture data from the link frame following the de-assertion of their SSYNC bit.
4.6.7.3
Stream-to-Stream Stop Synchronization
•
The sequence starts while relevant streams are actively receiving (input) or transmitting (output). Their respective RUN bits are set to 1 while SSYNC bits are cleared to 0.•
To begin the synchronized stop, software writes a 1 to the relevant SSYNC bits. As a result of the SSYNC bits being set, the controller will stop receiving (input) or transmitting (output) in the beginning of the next frame for the relevant streams. Software may then clear each individual streams’ RUN bits to 0 to stop the stream’s DMA engine.•
Once software detects that all relevant RUN bits are cleared to 0, it can clear the SSYNC bits to a 0 to return the controller to the initial ready state. Software can then restart the streams using the same sequence described in Section 4.5.7.2, or it may start them individually without using the SSYNC bits.Intel® High Definition Audio Programming Model
4.6.8
Power Management
4.6.8.1
Power State Transitions
When the controller or codecs are transitioned to a D0 state from a D3 state, it is possible that the hardware may have had power removed, and, therefore, software must not assume that registers retain values previously programmed, with the exception of controller registers marked “RSM.” Software should therefore restore all codec registers on a transition to D0 from D3.
4.6.8.2
Power Optimization
While there is no requirement that software perform power optimizations, in many environments power savings are desired. Software may optimize at three levels. The easiest power management level is using the CRST bit in the controller to power up or down the entire controller and link at once. This method is obviously not always suitable, as any activity on the link to any codec will prevent software from entering this state. This state also takes the longest to resume from, as the entire subsystem including the controller and codec must be reinitialized before a stream can be started.
Software may also control power at the Function Group level by using the Power State Control at the Function Group level. This method is generally sufficient for most systems, especially where there are multiple function groups on the link, such as audio and modem. In this case, function groups not in use may be shut down without affecting the operation of other function groups. To achieve optimal power conservation, software may use widget level power controls to shut down widgets not in use. In the example case of an audio function group, software may be able to shut down amplifiers and other power consuming components in the codecs without affecting active streams using other paths in the codec. The actual level of power savings may vary
considerably, as different codec hardware implementations may make different power usage versus complexity tradeoffs.