Possible bug, with extreme low latency audio.

Possible bug, with extreme low latency audio.

[Uwaysi Bin Kareem]

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.

Re: Possible bug, with extreme low latency audio.

[Clemens Ladisch]

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

Re: Possible bug, with extreme low latency audio.

[Uwaysi Bin Kareem]

On Tue, 01 Mar 2011 11:57:18 +0100, Clemens Ladisch <clemens@ladisch.de>  
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.

Re: Possible bug, with extreme low latency audio.

[Clemens Ladisch]

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

Re: Possible bug, with extreme low latency audio.

[Uwaysi Bin Kareem]

On Wed, 02 Mar 2011 08:28:50 +0100, Clemens Ladisch <clemens@ladisch.de>
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.

Re: Possible bug, with extreme low latency audio.

[Uwaysi Bin Kareem]

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.

Renicing for OpenGL smoothness.

[Uwaysi Bin Kareem]

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.