Linux Sound subsystem development
 help / color / mirror / Atom feed
From: Benno Senoner <sbenno@gardena.net>
To: linux-sound@vger.kernel.org
Subject: low-latency benchmarks: excellent results of RTC clock + SIGIO notification, audio-latency now down
Date: Sat, 11 Sep 1999 15:42:35 +0000	[thread overview]
Message-ID: <marc-linux-sound-93706455029492@msgid-missing> (raw)

Hi,
good news folks:

Paul Barton Davis added async notification via SIGIO to the RTC device,
and I enhanced "latencytest" (you can get the latest version from my page) to
measure timedifferences between two SIGIO calls, All benchmarks performed using
Mingo's low-latency patch (without his patch timing sucks)
The results are very good,
In my example I used an RTC frequency of 2048HZ, and the maximum jitter was
about 500usecs (very sporadic , shows up every 60-100secs).

look at the the results:
CPU load€%
http://www.gardena.net/benno/linux/audio/rtc2048-cpu80/2048.html

CPU load\x10%
http://www.gardena.net/benno/linux/audio/rtc2048-cpu10/2048.html

A typical use could be an app which needs 1ms timing precision
( MIDI sequencer for example).


I have more good news,  On my audio benchmarks I was able to
reduce the audio buffer size from 4.3ms to ONLY 2.1ms ( 3x0.7ms buffers) ! ,
without losing reliability ,in this case the max jitter is about  0.7ms  in the
range of the fragment-time.

look at the results:
CPU load€%
http://www.gardena.net/benno/linux/audio/audio3x128-cpu80/3x128.html

CPU load\x10%
http://www.gardena.net/benno/linux/audio/audio3x128-cpu10/3x128.html

It's interesting that If I use 4.3ms = 3x1.45ms buffers, the max jitter (again
very sporadic) is about 1.5ms , the time it takes to play one fragment.  

Seems that under high disk I/O load,
(very seldom, about every 30-100secs) the process
gets woken up one IRQ period later.
Ideas why this happens.

The trick to deliver rock-solid audio seems to use 3 buffer, so that you can
have about 33% headroom.

Seems that we are now able to outperform most of the other OSes in terms of 
timing precision/ latency ( multimedia loves this)
:-)

In future, we will probably not need RT-Linux to deliver realtime audio
on Linux. (As processors get faster , jitter will go down)

comments ?

regards,
Benno.


---
Benno Senoner
E-Mail: sbenno@gardena.net
Linux low latency audio / scheduling latency benchmarks
http://www.gardena.net/benno/linux/audio

             reply	other threads:[~1999-09-11 15:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-09-11 15:42 Benno Senoner [this message]
1999-09-11 15:46 ` low-latency benchmarks: excellent results of RTC clock + SIGIO mingo
1999-09-11 16:12 ` low-latency benchmarks: excellent results of RTC clock + SIGIO notification, audio-latency now d Benno Senoner

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=marc-linux-sound-93706455029492@msgid-missing \
    --to=sbenno@gardena.net \
    --cc=linux-sound@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox