Possible bug, with extreme low latency audio.

Hello.

I have shaved a kernel for features I suspected to add to os-jitter, to get the lowest possible latency from it. The kernel is 2.6.36-zen0
The .config is http://www.paradoxuncreated.com/tmp/.config

What happens is, if I set my audioapp, (renoise) to extremely low latencies, (96khz, 8 samples buffers x 2), the audio seems to be distorting and speeding up, while having periods of normal playback.

With other kernel configurations, I have just experienced, glitches, which is typical of buffer underruns.
This kernel config though, reduces the overall os-jitter, so I could push the latency much lower. However then I stumbled on this problem.

Best Regards,
Uwaysi.

I'd guess that buffer is so small that it's smaller than the DMA FIFO and/or the DMA burst size of the sound device (whatever it is) so that the DMA controller is not able to accurately report the current position in the buffer.

Obviously, the lowest possible latency is higher than 167 µs.

Regards,
Clemens

Actually I have to different audiocards here. The one with the problem is an nvidia onboard soundchip.
It seems to behave like this, with my current .config, with latencies below 1 ms. With an unshaved earlier .config, on 2.6.33, latencies would not go below 1 ms on this card, but the audio would become noisy and distorted. On 2.6.36 this has changed to 0.5ms. And shaving the kernel, allows one to go even lower.

00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2)
Subsystem: Micro-Star International Co., Ltd. Device 7380
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22 Memory at f9ff8000 (32-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: HDA Intel
Kernel modules: snd-hda-intel

The other is a firewire device (Konnekt24d using FFADO, running on the old firewire stack).
The firewire device actually plays nicely without much buffer underruns down to 0.363 ms latency (8x2 @ 44.1k).
However it seems to choke at 8x2 @ 96k. Glitching, because of buffer underruns aren't the main problem here either, but the sound will disappear for large amounts of time.

FireWire packets are sent every 125 µs; for audio, every packet contains either zero or eight samples, and the proportion of data and no-data packets is adjusted so that the overall rate is 44100 samples per second. So 8x2 is the theoretical minimum.

At sample rates above 48 kHz, there are 16 samples per packet (and above 96 kHz, 32). It is not possible to use 8x2 at 96 kHz, and FFADO should not have allowed you to try it; please file a bug there:
<http://subversion.ffado.org/report> (requires a login).

Regards,
Clemens

Ok, I am hitting the hardware limits. I'll inform FFADO crew about this. There are probably more bound to hit this limit, as lowlatency operation with Linux, is getting this good. A good error msg with the above information, would be good.

Best Regards,
Uwaysi.

Btw, the bug with speeding up etc, is not present on 2.6.38-rc7, so it can be an issue with 2.6.36-zen0 which has BFS scheduler.

Hiya. I'm sitting here playing some OpenGL games, and thinking, isn't it rude of processes demanding the same amount of cpu, when I am here, wanting the smoothest possible OpenGL experience.

So I am renicing. But my knowledge of the kernel is limited. So I was thinking, maybe some of you could inform me, which processes are involved in getting the graphics on-screen.

I have already started making a renicing script.

---

highpri=-20;
lowpri=19;
for pid in pgrep ""; do renice -n $lowpri -p $pid; done #ubuntu runs a lot of processes that can be put in the background.
for pid in pgrep "init"; do renice -n $highpri -p $pid; done #probably good to have high priority?
for pid in pgrep "kthreadd"; do renice -n $highpri -p $pid; done #does drivers or anything else create kernel threads that are involved in the graphics on-screen? for pid in pgrep "ksoftirq"; do renice -n $highpri -p $pid; done #surely these are?
for pid in pgrep "X"; do renice -n $highpri -p $pid; done
for pid in pgrep "metacity"; do renice -n $highpri -p $pid; done
for pid in pgrep "hd-audio0"; do renice -n $highpri -p $pid; done

--
Comments and information appreciated.