hier ein statement:
Hier die ganze Seite:Nowadays, a majority of operating systems are time-sharing and multi-tasks, and it goes from the process scheduling on the top to the interrupt scheduling on the bottom, and finally data will be sent to the hardware. Most interruptions of the operating system deem 100Hz or so as a tick of the clock. To put it this way, it takes at least 10ms for the application program to get scheduled. Moreover, due to large amounts of application programs in the system, the audio application system does not enjoy the top priority. As for the bottom, various interruptions need tackling, i.e. network interruption and display/video interruption with the audio handling ranking behind them. Therefore, it results in a great many jitters. It is the key that pales PCHiFi in comparison with CDP. The player in an operating system amounts to an independent Mini PCHiFi.
In an operating system, audio application (player) belongs to the application layer, and a few audio data will be sent to the operating system at intervals. A great many of other applications in the application layer will occupy CPU resource intermittently. The player has to wait for the CPU resource until it is available. Only after that can the audio data be sent to the operating system. Therefore, the more applications in a system, the less likely the audio application receives prompt handling, let alone sends data to the operating system in time.
Next, the kernel sends the data to the hardware. The kernel is interactive by means of the driver that calls audio device and the hardware. All the motive powers stem from system interruption. Every time the hardware is interrupted, CPU will respond accordingly, figure out which device is on a break and call interrupt program to tackle the problem, read data from the hardware, or write data into the interrupt program. As is shown, various interruptions exist in the system. If any interruption of high priority happens in the middle of handling the one of low priority, the high priority will come first. Lots of interruptions rank before audio interruption. That’s why audio response may fail to receive prompt handling in operating system, resulting in jitters.
Recent years have witnessed the emergence of a USB decoder which is asynchronous. In order to solve the problem, a cache of 8M is integrated enabling nearly 3 seconds’ caching of audio data. Set aside the audio quality, this approach fully demonstrates that the designer doesn’t have much faith in the real time of audio output in an operating system.
http://www.qlshifi.com/en/wzcapi/qa660.htm
Gruß
Bernd Peter
