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

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

[Karsten Wiese]

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

regards,
Karsten

__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Möchten Sie mit einem Gruß antworten? http://grusskarten.yahoo.de


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

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

[Takashi Iwai]

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

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

[Tim Goetze]

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? What
kind of hw/sw params, especially period size, should one set? Can
one choose larger period sizes (45 frames/cycle is too tough for a
userspace process, at least on this box)?

tim



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

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

[Takashi Iwai]

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

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

[Tim Goetze]

Takashi Iwai wrote:

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

Yeah, a differing number of frames/cycle makes things hairy. But if
one sets a period size of 45/90 frames/cycle and accepts 44/88/89 as
well, things should work OK, shouldn't they?

>> What kind of hw/sw params, especially period size, should one set?
>
>the frequency aligned to 1000Hz.

You mean divided by 1000, rounded up to the nearest integer, right?

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

Thanks!

tim



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

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

[Takashi Iwai]

At Tue, 20 Aug 2002 13:34:03 +0200 (CEST),
Tim Goetze wrote:
> 
> Takashi Iwai wrote:
> 
> >> 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.
> 
> Yeah, a differing number of frames/cycle makes things hairy. But if
> one sets a period size of 45/90 frames/cycle and accepts 44/88/89 as
> well, things should work OK, shouldn't they?

well... for that, you have to know how much data to be written
_before_ actually you writing it.  i.e. you need an extra step, query
the (rest) period size -> then write/read, instead of always writing
the same amount of data.


> >> What kind of hw/sw params, especially period size, should one set?
> >
> >the frequency aligned to 1000Hz.
> 
> You mean divided by 1000, rounded up to the nearest integer, right?

yes.


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

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

[Tim Goetze]

Takashi Iwai wrote:

>At Tue, 20 Aug 2002 13:34:03 +0200 (CEST),
>Tim Goetze wrote:
>> 
>> Takashi Iwai wrote:
>> 
>> >> 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.
>> 
>> Yeah, a differing number of frames/cycle makes things hairy. But if
>> one sets a period size of 45/90 frames/cycle and accepts 44/88/89 as
>> well, things should work OK, shouldn't they?
>
>well... for that, you have to know how much data to be written
>_before_ actually you writing it.  i.e. you need an extra step, query
>the (rest) period size -> then write/read, instead of always writing
>the same amount of data.

Sorry, I don't get it.

You mean update_avail will return a higher number of frames than
snd_pcm_mmap_begin, so one has to mmap_begin a second time? That
would be proceeding as usual.

tim



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

Correct me if I am wrong & few questions

[Shaju Abraham]

Hi all,
           The following is my understanding ....pls correct me if I am
wrong.

1.     Buffer_size is how much of memory has been allocated to buffer the
sound to be played out.

2.     Fragment size is the measure of amount of data played between two
consecutive interrupts raised by the card.

3.    frags is the count of fragments the buffer (of size buffer_size ) has
been divided into.  ( frags may be more than the number of bds available i.e
32 ) ..  Hence it follows that

4.     Both of the following two cases are possible, right?

                     i) the whole buffer (of size buffer_size ) can be
divided between 32 bds so that a given bd will always point to same address
during the ourse of emptying the buffer

                    ii) If I force the fragment size to be small, the big
buffer_size can be get divided into more than 32 frags.  So a given bd will
be pointing to different places in the buffer during              the course
of emptying the buffer.


Now I have a few questions pls.

1.    The number of fragments i.e frags won't increase beyond 1024.  is this
correct?  Because given a big buffer_size, I am unable to force the fragment
size to be smaller than a certain size .( the final size being such that
frags is 1024 )

2.    What is the relation between runtime->period_size, runtime->periods
and runtime->buffersize  ( in pcm_native.c ) and ichdev->size ,
ichdev->period_size, ichdev->frags ( in intel8x0.c)

3.    I have a situation where I do not want to use all of the 32 bds
available. I want to use say only 2 or 4 of the bds with each bd pointing to
only a small fragment of data.( This is basically to give rise to a
condition where the card will not be able to proceed if the interrupts
raised by the past bds have not been serviced. 32 is a big number. I want to
restrict it to 2 or 4 ) . So, ..

            i)  What is the significance of ICH_MAX_FRAGS?  It seems to be
used only for the allocation of pages for the buffer and for little else
during the actual functioning of the card.

            ii)    What is the significance of ICH_REG_LVI_MASK?  (This is
more used during the actual functioning of the card & is used in the
interrupt service sub-routine to update the lvi.)  It is by default 0x1f .
Is this 'cos it can be used to address the 32 bds available.  I changed this
to 3 and 7 . I observed that this makes the card to use only 4 or 8 of the
bds available. Am I correct in this conclusion?  If I do this, I get some
noise. Is this because of the interrupts raised by the unused bds?

            iii) If I am wrong abt all this, how should I go abt my idea of
using only 2 or 4 of the bds available?


Clarifications on any points in the mail are welcome.


Thanx in advance,
--Shaju



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

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

[Paul Davis]

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

this isn't true, or if it is true, it can be fixed fairly easily. what
you might mean is that some JACK clients won't run well under such
circumstances, but the JACK alsa driver/client is written to "present"
uniform "period" sizes to JACK. the fact that the ALSA driver itself
doesn't do this won't affect JACK - we will instead still break up the
"stream" into uniform-sized chunks. 

--p


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