Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Revell <rlrevell@joe-job.com>
To: Alsa-devel@lists.sourceforge.net
Subject: emu10k1 latency / capture period
Date: Wed, 16 Jun 2004 16:14:51 -0400	[thread overview]
Message-ID: <1087416890.25102.21.camel@debian> (raw)

Hey,

I am having a problem with the emu10k1 driver where I am unable to set
the capture period lower than 512.  The result is that the lowest
achievable input to output latency is in the neighborhood of 40ms.

I have tried with several different ALSA versions, from 0.9 through the 
latest CVS as of yesterday.

Here is the output from running the 'latency' test program from
alsa-lib.

debian:/usr/src/alsa-cvs/alsa-lib/test# ./latency -m 1024 -M 1024  -t 1
-p
Scheduler set to Round Robin with priority 99...
Playback device is hw:0,0
Capture device is hw:0,0
Parameters are 22050Hz, S16_LE, 2 channels, non-blocking mode
Wanted tick time: 1us, poll mode: yes
Loop limit is 661500 frames, minimum latency = 1024, maximum latency =
1024
Hardware PCM card 0 'Sound Blaster Audigy2' device 0 subdevice 0

Its setup is:
stream       : PLAYBACK
access       : RW_INTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 2
rate         : 22050
exact rate   : 22050 (22050/1)
msbits       : 16
buffer_size  : 1024
period_size  : 512
period_time  : 23219
tick_time    : 1000
tstamp_mode  : NONE
period_step  : 1
sleep_min    : 1
avail_min    : 16
xfer_align   : 4
start_threshold  : 2147483647
stop_threshold   : 1024
silence_threshold: 0
silence_size : 0
boundary     : 1073741824
Hardware PCM card 0 'Sound Blaster Audigy2' device 0 subdevice 0

Its setup is:
stream       : CAPTURE
access       : RW_INTERLEAVED
format       : S16_LE
subformat    : STD
channels     : 2
rate         : 22050
exact rate   : 22050 (22050/1)
msbits       : 16
buffer_size  : 1024
period_size  : 512
period_time  : 23219
tick_time    : 1000
tstamp_mode  : NONE
period_step  : 1
sleep_min    : 1
avail_min    : 16
xfer_align   : 4
start_threshold  : 2147483647
stop_threshold   : 1024
silence_threshold: 0
silence_size : 0
boundary     : 1073741824
Trying latency 1024 frames, 46439.909us, 46.439909ms (21.5332Hz)
Using tick time 1000us
Success
Playback:
*** frames = 662528 ***
state       : RUNNING
trigger_time: 1087415794.855524000
tstamp      : 1087415824.860520000
delay       : 1022
avail       : 2
avail_max   : 38
Capture:
*** frames = 661504 ***
state       : RUNNING
trigger_time: 1087415794.855428000
tstamp      : 1087415824.860645000
delay       : 40
avail       : 40
avail_max   : 56
Maximum read: 56 frames
Maximum read latency: 2539.683us, 2.539683ms (393.7500Hz)
Playback time = 1087415794.855524, Record time = 1087415794.855428, diff
= 96

Here is what happens when I try to set the peiod size any lower:

debian:/usr/src/alsa-cvs/alsa-lib/test# ./latency -m 512 -M 512  -t 1 -p
Scheduler set to Round Robin with priority 99...
Playback device is hw:0,0
Capture device is hw:0,0
Parameters are 22050Hz, S16_LE, 2 channels, non-blocking mode
Wanted tick time: 1us, poll mode: yes
Loop limit is 661500 frames, minimum latency = 512, maximum latency =
512

It just exits.

I have the same problem with JACK, attempting to set the period size
lower than 512 results in an error.

I know that the hardware is capable of much lower latencies than this,
as there are two different ASIO drivers available on Windows for this
card that provide latencies in the 2-5ms range.

I have posted this to linux-audio-dev and elsewhere, so far I am not
getting much of a response other than 'yes, I have that problem too'. 
It seems to be universally acknowledged but there is not a lot being
done about it.  I have seen a lot of claims to the effect that the
design of ALSA is superior to ASIO, that it allows more than two
interrupts per buffer, etc. - so why are the ALSA drivers for this very
common device an order of magnitude worse in latency than the ASIO
drivers?

Are there any plans to address this?

Lee



-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND

             reply	other threads:[~2004-06-16 20:14 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-16 20:14 Lee Revell [this message]
2004-06-16 20:52 ` emu10k1 latency / capture period James Courtier-Dutton
2004-06-16 21:02   ` Lee Revell
2004-06-20  4:06 ` Lee Revell
2004-06-21 15:35   ` Takashi Iwai
2004-06-21 15:54     ` Takashi Iwai
2004-06-21 20:20       ` Lee Revell
2004-06-22 11:13         ` Takashi Iwai
2004-06-22 11:29           ` Jaroslav Kysela
2004-06-22 12:47             ` Takashi Iwai
2004-06-22 21:15               ` Lee Revell
2004-06-28 20:44               ` Lee Revell
2004-06-22 20:26             ` Lee Revell
2004-06-22 18:48           ` Lee Revell
2004-06-21 20:25     ` Lee Revell
2004-07-08  0:40     ` Lee Revell
  -- strict thread matches above, loose matches on Subject: below --
2004-06-17  9:06 Peter Zubaj
2004-06-17 18:37 ` Lee Revell
2004-06-17 23:26   ` Paul Davis
2004-06-18  9:33     ` Takashi Iwai
2004-06-18 19:39       ` Lee Revell
2004-06-18 23:26       ` Lee Revell
2004-06-21  8:03 Peter Zubaj
2004-06-21 15:26 ` Takashi Iwai
2004-06-21 20:27   ` Lee Revell

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=1087416890.25102.21.camel@debian \
    --to=rlrevell@joe-job.com \
    --cc=Alsa-devel@lists.sourceforge.net \
    /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