From: Uwaysi Bin Kareem <uwaysi.bin.kareem@paradoxuncreated.com>
To: linux-kernel@vger.kernel.org, clemens@ladisch.de
Subject: Re: Possible bug, with extreme low latency audio.
Date: Tue, 01 Mar 2011 17:59:27 +0100 [thread overview]
Message-ID: <op.vrob5de16426ze@millennium> (raw)
In-Reply-To: <4D6CD10E.3050805@ladisch.de>
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.
next prev parent reply other threads:[~2011-03-01 16:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-01 0:58 Possible bug, with extreme low latency audio Uwaysi Bin Kareem
2011-03-01 10:57 ` Clemens Ladisch
2011-03-01 16:59 ` Uwaysi Bin Kareem [this message]
2011-03-02 7:28 ` Clemens Ladisch
2011-03-02 20:01 ` Uwaysi Bin Kareem
2011-03-03 19:07 ` Uwaysi Bin Kareem
2011-03-04 3:36 ` Renicing for OpenGL smoothness Uwaysi Bin Kareem
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=op.vrob5de16426ze@millennium \
--to=uwaysi.bin.kareem@paradoxuncreated.com \
--cc=clemens@ladisch.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.