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.
Uwaysi Bin Kareem wrote:
> I have shaved a kernel for features I suspected to add to os-jitter, to
> get the lowest possible latency from it.
>
> 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.
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
On Tue, 01 Mar 2011 11:57:18 +0100, Clemens Ladisch <[email protected]>
wrote:
> Uwaysi Bin Kareem wrote:
>> I have shaved a kernel for features I suspected to add to os-jitter, to
>> get the lowest possible latency from it.
>>
>> 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.
>
> 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.
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.
Uwaysi Bin Kareem wrote:
> 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).
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.
> However it seems to choke at 8x2 @ 96k.
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
On Wed, 02 Mar 2011 08:28:50 +0100, Clemens Ladisch <[email protected]>
wrote:
> Uwaysi Bin Kareem wrote:
>> 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).
>
> 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.
>
>> However it seems to choke at 8x2 @ 96k.
>
> 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).
>
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.
> 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.
Well, there's just two processes that I couldn't find information on
online though, kintegrityd and kworker. I set them to highpri for the
moment, in my script. However the script didn't seem to make much of a
difference, so the processes that run on Ubuntu Natty Narwhal seems to be
quite well behaved. It's just a principle though, that any background
processes shouldn't be able to request a lot of cpu, while I am running my
opengl app. I do see that the ubuntu folks have reniced some processes of
their own though.
[khelper] [kintegrityd] [kblockd] [kacpid] [kacpi_notify] [kacpi_hotplug]
[ata_sff] and more are all at -20. Seems to be quite the opposite of what
I am doing...