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
next 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