On Fri, Jun 07, 2013 at 04:06:15PM +0200, pet...@schwertfisch.de wrote: > > In what way will audio be unreliable (or non-deterministic) when > inteldrm is enabled?
While the CPU is running in kernel code (eg, syscall), programs cannot submit audio data before the syscall completes (or releases the CPU by sleeping). If the device has no data to play, it inserts a block of silence which results in "stuttering". On the contrary, any program running in user-mode, can be preempted by the audio program, which can manage to submit audio data in time to the device. The X server, when using the inteldrm driver, involves a lot the kernel to run hardware accelerated graphic operations. This prevents other programs to get the CPU and to submit audio data in time. On the other hand, X, when using the vesa driver, maps the video memory in its address space during initialization; then it access it without involving the kernel, allowing audio programs to run concurently. The symptom is not specific to the inteldrm driver, but to any cpu-intensive kernel code or to programs using (abusing) too much kernel services. The most notable subsystems hurting audio are uvm and kernel crypto. This holds for SP kernels. The problem becomes agravated by MP kernels because interrupts of the audio device may be missed while programs on a secondary cpu are running in kernel mode. -- Alexandre
