Re: usb-audio: variable periodsize / nframes per callback can shorten latency times

[Takashi Iwai <tiwai@suse.de>]

At Mon, 19 Aug 2002 15:17:51 +0200,
Karsten Wiese wrote:
> 
> Hi,
> 
> usb iso transfers happen every 1ms (USB1.1) ( or at multiples of 125µs for
> USB2.0).
> this timing is fixed and leads to a variable amount of frames available at
> interrupt.
> looking at 44100Hz on USB 1.1, we receive/send 44 frames on 9 of 10
> USB-interrupts and 45 frames on 1 of 10
> USB-interrupts.
> on first sight 48000Hz seams to lead to a constant 48 frames per interrupt.
> this does not remain true if the USB-audio device is in sync to an
> externally connected device (digital in).
> the current usb-audio mimics constant period size in the USB-interrupt
> routines by calling snd_period_elapsed() only, if at least full period sizes
> are transfered on the usb.

well, this is a workaround.
as you pointed out, basically the period size must be aligned to the
time not to the frames.
however, the current implementation of alsa driver assumes that the
period size in frames.  although you can specify the period time, the
period size will be aligned to the frames at the final stage.

> this good for constant period-size compatibility but leads to sub-optimal
> latency: i.e. for capture worst case, audio apps start working 1ms later
> than possible.

yep.

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


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