From: Takashi Iwai <tiwai@suse.de>
To: Tim Goetze <tim@quitte.de>
Cc: Karsten Wiese <annabellesgarden@yahoo.de>,
Alsa-Devel <alsa-devel@alsa-project.org>
Subject: Re: usb-audio: variable periodsize / nframes per callback can shorten latency times
Date: Tue, 20 Aug 2002 12:55:32 +0200 [thread overview]
Message-ID: <s5hlm71sst7.wl@alsa2.suse.de> (raw)
In-Reply-To: <Pine.LNX.4.21.0208201214450.682-100000@summer.quitte>
At Tue, 20 Aug 2002 12:30:11 +0200 (CEST),
Tim Goetze wrote:
>
> Takashi Iwai wrote:
>
> >> How can we implement the latency-optimal behaviour with alsa-driver
> >> framework?
> >> Can we implement something like a snd_1ms_elapsed() routine (called from
> >> USB-interrupt), which in turn triggers a waiting app with the available
> >> period size (which would be 44 or 45 frames for 44100Hz)?
> >> I would like to see this in ALSA / JACK.
> >> What do you think?
> >
> >hmm, it's not so easy, since this will break also the assumption of
> >constant period "frames" by applications. if we introduce the
> >time-based period size, it won't work as compatible as older one,
> >e.g. jack wouldn't run properly if the period size changes
> >dynamically.
> >hence, this should be handled in a special case.
>
> With the current setup and cycle code for mmap'd IO (like Jack for
> example does it), is it possible to use these devices at all?
on 48kHz my usb speaker worked fine with 1ms or 2ms period size (not
under high loads, though), since the frames per urb becomes integer in
this case. on 44.1kHz xrun could happen.
> What kind of hw/sw params, especially period size, should one set?
the frequency aligned to 1000Hz.
> Can one choose larger period sizes (45 frames/cycle is too tough for
> a userspace process, at least on this box)?
of course, depending on the kernel :)
in theory, 1ms latency is enough possible.
ciao,
Takashi
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
next prev parent reply other threads:[~2002-08-20 11:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-19 13:17 usb-audio: variable periodsize / nframes per callback can shorten latency times Karsten Wiese
2002-08-19 15:38 ` Takashi Iwai
2002-08-20 10:30 ` Tim Goetze
2002-08-20 10:55 ` Takashi Iwai [this message]
2002-08-20 11:34 ` Tim Goetze
2002-08-20 17:15 ` Takashi Iwai
2002-08-20 20:27 ` Tim Goetze
2002-08-21 5:40 ` Correct me if I am wrong & few questions Shaju Abraham
2002-08-27 14:19 ` usb-audio: variable periodsize / nframes per callback can shorten latency times Paul Davis
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=s5hlm71sst7.wl@alsa2.suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=annabellesgarden@yahoo.de \
--cc=tim@quitte.de \
/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.