Re: irq handler top half timestamps

Re: irq handler top half timestamps

[Lee Revell]

On Thu, 2004-12-09 at 22:07 +0100, Florian Schmidt wrote:
> On Thu, 9 Dec 2004 19:33:42 +0100
> Ingo Molnar <mingo@elte.hu> wrote:
> 
> > cleanest would be to somehow make this part of ALSA, just like xrun info
> > is part of ALSA (the two are related as well). But there are other
> > details too i guess: a single audio device can have separate interrupts
> > (for playback and capture?) - in that case which one should ALSA return?
> 
> Well, possibly ALSA could keep the timestamps for each substream around?
> And the ioctl should get parametrized with the substream # so it returns
> the most current irq timestamp for the selected substream.
> 

Doesn't ALSA already do this?  IIRC when you call snd_pcm_period_elapsed
in the ALSA irq handler the PCM stream is timestamped.

Lee



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: [Jackit-devel] irq handler top half timestamps

[Florian Schmidt]

On Thu, 09 Dec 2004 16:10:28 -0500
Lee Revell <rlrevell@joe-job.com> wrote:

> On Thu, 2004-12-09 at 22:07 +0100, Florian Schmidt wrote:
> > On Thu, 9 Dec 2004 19:33:42 +0100
> > Ingo Molnar <mingo@elte.hu> wrote:
> > 
> > > cleanest would be to somehow make this part of ALSA, just like xrun info
> > > is part of ALSA (the two are related as well). But there are other
> > > details too i guess: a single audio device can have separate interrupts
> > > (for playback and capture?) - in that case which one should ALSA return?
> > 
> > Well, possibly ALSA could keep the timestamps for each substream around?
> > And the ioctl should get parametrized with the substream # so it returns
> > the most current irq timestamp for the selected substream.
> > 
> 
> Doesn't ALSA already do this?  IIRC when you call snd_pcm_period_elapsed
> in the ALSA irq handler the PCM stream is timestamped.

To what kind of timestamp do you refer here? We need a timestamp
relative to a clock that jackd can use, too. Like for example TSC or
RTC. 

Just to give a rundown on the subject to the alsa-devel people. On
jackit-devel we are currently faced with the problem of estimating the
times at which the irq's for the soundcard were actually raised [to be
able to map arbitrary other times to the framecount of the frame
actually sounding at that moment]. For this we timestamp the time that
jackd is actually woken and try to estimate the real irq time from that.

Of course a much better estimate can be achieved if the scheduling
latencies which might occur between raising the IRQ and waking jackd are
eliminated. The earliest place such a timestamp can be taken is in the
top half irq handler.

So it would be very useful, if, for example, the top half irq handler of
the alsa driver would timestamp each IRQ with i.e. a TSC timestamp and
expose this timestamp to the application in userspace.

Flo

-- 
Palimm Palimm!
http://affenbande.org/~tapas/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: [Alsa-devel] Re: irq handler top half timestamps

[Jaroslav Kysela]

On Fri, 10 Dec 2004, Florian Schmidt wrote:

> So it would be very useful, if, for example, the top half irq handler of
> the alsa driver would timestamp each IRQ with i.e. a TSC timestamp and
> expose this timestamp to the application in userspace.

We can do any timestamp in the IRQ handler (this enum can be extended):

enum sndrv_pcm_tstamp {
        SNDRV_PCM_TSTAMP_NONE = 0,
        SNDRV_PCM_TSTAMP_MMAP,
        SNDRV_PCM_TSTAMP_LAST = SNDRV_PCM_TSTAMP_MMAP,
};

And this structure is used to store timestamp value:

struct timespec tstamp;

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: [Alsa-devel] Re: irq handler top half timestamps

[Florian Schmidt]

On Fri, 10 Dec 2004 08:52:39 +0100 (CET)
Jaroslav Kysela <perex@suse.cz> wrote:

> On Fri, 10 Dec 2004, Florian Schmidt wrote:
> 
> > So it would be very useful, if, for example, the top half irq handler of
> > the alsa driver would timestamp each IRQ with i.e. a TSC timestamp and
> > expose this timestamp to the application in userspace.
> 
> We can do any timestamp in the IRQ handler (this enum can be extended):
> 
> enum sndrv_pcm_tstamp {
>         SNDRV_PCM_TSTAMP_NONE = 0,
>         SNDRV_PCM_TSTAMP_MMAP,
>         SNDRV_PCM_TSTAMP_LAST = SNDRV_PCM_TSTAMP_MMAP,
> };
> 
> And this structure is used to store timestamp value:
> 
> struct timespec tstamp;

Way cool! But how to access it from userspace?

Flo

-- 
Palimm Palimm!
http://affenbande.org/~tapas/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: [Jackit-devel] irq handler top half timestamps

[Paul Davis]

>> We can do any timestamp in the IRQ handler (this enum can be extended):
>> 
>> enum sndrv_pcm_tstamp {
>>         SNDRV_PCM_TSTAMP_NONE = 0,
>>         SNDRV_PCM_TSTAMP_MMAP,
>>         SNDRV_PCM_TSTAMP_LAST = SNDRV_PCM_TSTAMP_MMAP,
>> };
>> 
>> And this structure is used to store timestamp value:
>> 
>> struct timespec tstamp;
>
>Way cool! But how to access it from userspace?

i was remembering this the other day. just a quick note: the timestamp
will be taken in the "bottom half" handler, which hopefully makes no
difference for JACK purposes because the audio interface IRQ is not
threaded.

--p


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: [Alsa-devel] Re: irq handler top half timestamps

[Florian Schmidt]

On Fri, 10 Dec 2004 12:17:35 -0500
Paul Davis <paul@linuxaudiosystems.com> wrote:

> >> We can do any timestamp in the IRQ handler (this enum can be extended):
> >> 
> >> enum sndrv_pcm_tstamp {
> >>         SNDRV_PCM_TSTAMP_NONE = 0,
> >>         SNDRV_PCM_TSTAMP_MMAP,
> >>         SNDRV_PCM_TSTAMP_LAST = SNDRV_PCM_TSTAMP_MMAP,
> >> };
> >> 
> >> And this structure is used to store timestamp value:
> >> 
> >> struct timespec tstamp;
> >
> >Way cool! But how to access it from userspace?
> 
> i was remembering this the other day. just a quick note: the timestamp
> will be taken in the "bottom half" handler, which hopefully makes no
> difference for JACK purposes because the audio interface IRQ is not
> threaded.

Hi,

i think this assumption is not always true. On a realtime preemptive
kernel, the bottom half of the alsa irq handler can run in a thread. In
the normal jackd usage case this thread should probably be the highest
priority thread in the system and this should eliminate most scheduling
delays. I still think the best way [also with respect to variable length
code paths in the bottom handler before taking the timestamp
(speculation on my part)] would be to take the timestamp in the top half
if that's possible. Bottom half timestamp will probably still be better
than a timestamp taken in jackd though as we eliminate the (variable)
time needed for waking up jackd.

Flo

-- 
Palimm Palimm!
http://affenbande.org/~tapas/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: [Jackit-devel] irq handler top half timestamps

[Lee Revell]

On Fri, 2004-12-10 at 18:54 +0100, Florian Schmidt wrote:
> i think this assumption is not always true. On a realtime preemptive
> kernel, the bottom half of the alsa irq handler can run in a thread. In
> the normal jackd usage case this thread should probably be the highest
> priority thread in the system and this should eliminate most scheduling
> delays. I still think the best way [also with respect to variable length
> code paths in the bottom handler before taking the timestamp
> (speculation on my part)] would be to take the timestamp in the top half
> if that's possible. Bottom half timestamp will probably still be better
> than a timestamp taken in jackd though as we eliminate the (variable)
> time needed for waking up jackd.

Maybe I am not understanding the ALSA code correctly, but I was under
the impression that ALSA interrupt handlers do not really have a bottom
half as such, in that they do not schedule any work for later via
raising a softirq or scheduling a tasklet.  They just do it all in the
top half.  It's possible for ALSA to do everything in the top half
because all you do in an ALSA interrupt handler is call
snd_pcm_period_elapsed on one or more substreams.  For this to work it
seem like snd_pcm_period_elapsed has to be O(N) and therefore realtime
safe.

Am I getting this all wrong?

Lee





-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: [Jackit-devel] irq handler top half timestamps

[Paul Davis]

>Maybe I am not understanding the ALSA code correctly, but I was under
>the impression that ALSA interrupt handlers do not really have a bottom
>half as such, in that they do not schedule any work for later via
>raising a softirq or scheduling a tasklet.  They just do it all in the
>top half.  It's possible for ALSA to do everything in the top half
>because all you do in an ALSA interrupt handler is call
>snd_pcm_period_elapsed on one or more substreams.  For this to work it
>seem like snd_pcm_period_elapsed has to be O(N) and therefore realtime
>safe.

with ingo's RP patches, every IRQ has a top half and bottom half. the
question is whether the top half calls the bottom half directly or
arranges for it to run in a thread "later".

that's my understanding, anyway.

--p


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: [Jackit-devel] irq handler top half timestamps

[Lee Revell]

On Fri, 2004-12-10 at 15:51 -0500, Paul Davis wrote:
> >Maybe I am not understanding the ALSA code correctly, but I was under
> >the impression that ALSA interrupt handlers do not really have a bottom
> >half as such, in that they do not schedule any work for later via
> >raising a softirq or scheduling a tasklet.  They just do it all in the
> >top half.  It's possible for ALSA to do everything in the top half
> >because all you do in an ALSA interrupt handler is call
> >snd_pcm_period_elapsed on one or more substreams.  For this to work it
> >seem like snd_pcm_period_elapsed has to be O(N) and therefore realtime
> >safe.
> 
> with ingo's RP patches, every IRQ has a top half and bottom half. the
> question is whether the top half calls the bottom half directly or
> arranges for it to run in a thread "later".

Yeah, exactly.  I was speaking in terms of the traditional bottom
half/top half model.

With Ingo's patches we actually have 3 levels of IRQ context, they
effectively add a level above the traditional "top half" which is just a
tiny asm routine to mark the IRQ thread runnable (if threaded) or
execute the "real" top half directly if nonthreaded.

I don't really consider this new level very significant in practice
because it's fast and exactly the same for all devices.  IOW the
snd_pcm_period_elapsed timestamp should be good.  I don't think we need
to worry about the threaded ALSA IRQ case.

Lee



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: [Jackit-devel] irq handler top half timestamps

[Florian Schmidt]

On Fri, 10 Dec 2004 16:01:48 -0500
Lee Revell <rlrevell@joe-job.com> wrote:

> > with ingo's RP patches, every IRQ has a top half and bottom half. the
> > question is whether the top half calls the bottom half directly or
> > arranges for it to run in a thread "later".
> 
> Yeah, exactly.  I was speaking in terms of the traditional bottom
> half/top half model.
> 
> With Ingo's patches we actually have 3 levels of IRQ context, they
> effectively add a level above the traditional "top half" which is just a
> tiny asm routine to mark the IRQ thread runnable (if threaded) or
> execute the "real" top half directly if nonthreaded.

I see. For the best estimate, the timestamp would have to be taken as
soon as possible after the irq was raised. For this purpose alone it
would be great if that tiny asm routine actually would do the
timestamping, but i assume this would introduce some overhead (dunno, if
2 or 3 operations, or whatever is needed to read the TSC would really
count, but with the number of irqs happening, it might be
significant[??]). Also there would certainly extra code be needed to
pass this info along to the next irq handler stage..

> 
> I don't really consider this new level very significant in practice
> because it's fast and exactly the same for all devices.  IOW the
> snd_pcm_period_elapsed timestamp should be good.  I don't think we need
> to worry about the threaded ALSA IRQ case.

When exactly is snd_pcm_period_elapsed called? Is it called from the
ALSA driver interrupt handler (excuse, if this question is stupid, i'm
not too well versed (mildly speaking) when it comes to driver hacking)?
Is it the first thing in the irq handling routine?

Flo

-- 
Palimm Palimm!
http://affenbande.org/~tapas/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: [Jackit-devel] irq handler top half timestamps

[Florian Schmidt]

On Sat, 11 Dec 2004 01:56:10 +0100
Florian Schmidt <mista.tapas@gmx.net> wrote:

> > With Ingo's patches we actually have 3 levels of IRQ context, they
> > effectively add a level above the traditional "top half" which is just a
> > tiny asm routine to mark the IRQ thread runnable (if threaded) or
> > execute the "real" top half directly if nonthreaded.
> 
> I see. For the best estimate, the timestamp would have to be taken as
> soon as possible after the irq was raised. For this purpose alone it
> would be great if that tiny asm routine actually would do the
> timestamping, but i assume this would introduce some overhead (dunno, if
> 2 or 3 operations, or whatever is needed to read the TSC would really
> count, but with the number of irqs happening, it might be
> significant[??]). Also there would certainly extra code be needed to
> pass this info along to the next irq handler stage..

Oh, i almost forgot: Ingo has already posted a patch adding this to the
threaded irq handlers in recent RP kernels. ALSA could access it. But
making ALSA depend on a kernel feature of an experimental kernel might
be unwise (uneducated guess). 

Also this leaves the question of using a different timer source for the
timestamps in the case that TSC is unreliable open.

Is it sensible to require users of jackd to not use cpu freq scaling
during operation? If so, we could just settle on using the TSC.

Flo

* Ingo Molnar <mingo@elte.hu> wrote:

> the jackd IRQ timestamps are something different. We could record a
> timestamp in the tophalf handler, and let ALSA access it - the patch
> below implements this. [...]

new patch that actually compiles attached.

	Ingo

--- linux/kernel/irq/handle.c.orig	
+++ linux/kernel/irq/handle.c	
@@ -138,6 +138,11 @@ fastcall int handle_IRQ_event(unsigned i
 	return retval;
 }
 
+cycles_t irq_timestamp(unsigned int irq)
+{
+	return irq_desc[irq].timestamp;
+}
+
 /*
  * do_IRQ handles all normal device IRQ's (the special
  * SMP cross-CPU interrupts have their own specific
@@ -163,6 +168,7 @@ fastcall notrace unsigned int __do_IRQ(u
 		desc->handler->end(irq);
 		return 1;
 	}
+	desc->timestamp = get_cycles();
 
 	spin_lock(&desc->lock);
 	desc->handler->ack(irq);
--- linux/include/linux/irq.h.orig	
+++ linux/include/linux/irq.h	
@@ -77,6 +77,7 @@ typedef struct irq_desc {
 	unsigned int irqs_unhandled;
 	struct task_struct *thread;
 	wait_queue_head_t wait_for_handler;
+	cycles_t timestamp;
 	raw_spinlock_t lock;
 } ____cacheline_aligned irq_desc_t;
 
@@ -101,6 +102,7 @@ extern int can_request_irq(unsigned int 
 extern void early_init_hardirqs(void);
 extern void init_hardirqs(void);
 extern void init_irq_proc(void);
+extern cycles_t irq_timestamp(unsigned int irq);
 #else
 static inline void early_init_hardirqs(void) { }
 static inline void init_hardirqs(void) { }



-- 
Palimm Palimm!
http://affenbande.org/~tapas/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: [Alsa-devel] Re: irq handler top half timestamps

[Florian Schmidt]

On Sat, 11 Dec 2004 03:22:14 +0100
Florian Schmidt <mista.tapas@gmx.net> wrote:

> Oh, i almost forgot: Ingo has already posted a patch adding this to the
> threaded irq handlers in recent RP kernels. ALSA could access it. But
> making ALSA depend on a kernel feature of an experimental kernel might
> be unwise (uneducated guess). 
> 
> Also this leaves the question of using a different timer source for the
> timestamps in the case that TSC is unreliable open.
> 
> Is it sensible to require users of jackd to not use cpu freq scaling
> during operation? If so, we could just settle on using the TSC.
> 
> Flo
> 

is

snd_pcm_get_trigger_tstamp()

the api call to get the timestamp of the irq handler?

flo

-- 
Palimm Palimm!
http://affenbande.org/~tapas/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: [Alsa-devel] Re: irq handler top half timestamps

[Ingo Molnar]

* Florian Schmidt <mista.tapas@gmx.net> wrote:

> On Sat, 11 Dec 2004 03:22:14 +0100
> Florian Schmidt <mista.tapas@gmx.net> wrote:
> 
> > Oh, i almost forgot: Ingo has already posted a patch adding this to the
> > threaded irq handlers in recent RP kernels. ALSA could access it. But
> > making ALSA depend on a kernel feature of an experimental kernel might
> > be unwise (uneducated guess). 
> > 
> > Also this leaves the question of using a different timer source for the
> > timestamps in the case that TSC is unreliable open.
> > 
> > Is it sensible to require users of jackd to not use cpu freq scaling
> > during operation? If so, we could just settle on using the TSC.
> > 
> > Flo
> > 
> 
> is
> 
> snd_pcm_get_trigger_tstamp()
> 
> the api call to get the timestamp of the irq handler?
> 
> flo

in case you want to add it to ALSA within the -RT patchset, -RT now has
a generic function:

 extern cycles_t irq_timestamp(unsigned int irq);

the timestamps do get generated for every irq.

(but ... the usual disclaimer: this is just a playground thing, so
there's no guarantee of upstream merging.)

	Ingo


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: [Alsa-devel] Re: irq handler top half timestamps

[tapas]

On Thu, 16 Dec 2004 10:18:12 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> > is
> > 
> > snd_pcm_get_trigger_tstamp()
> > 
> > the api call to get the timestamp of the irq handler?
> > 
> > flo
> 
> in case you want to add it to ALSA within the -RT patchset, -RT now has
> a generic function:
> 
>  extern cycles_t irq_timestamp(unsigned int irq);
> 
> the timestamps do get generated for every irq.
> 
> (but ... the usual disclaimer: this is just a playground thing, so
> there's no guarantee of upstream merging.)

understood.

But the question of using a different timestamp source is still open in
case of the TSC's frequency not being constant. But i suppose this
question can wait until i figured out how to actually get the timestamp
from ALSA.

It looks like snd_pcm_get_trigger_tstamp() is the right call. And its
implementation would have to be adopted to use RP's
irq_timestamp(unsigned int irq)..

Fons Adriaenssen wrote to me that he tried snd_pcm_get_trigger_tstamp(),
but he always got the same value back. Since the docs are rather sparse
i want to ask the alsa-devs about exactly how to use the
snd_pcm_get_trigger_tstamp() call.

Any takers?

Flo


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: [Jackit-devel] irq handler top half timestamps

[Lee Revell]

On Thu, 2004-12-16 at 17:33 +0100, tapas wrote:
> Fons Adriaenssen wrote to me that he tried snd_pcm_get_trigger_tstamp(),
> but he always got the same value back. Since the docs are rather sparse
> i want to ask the alsa-devs about exactly how to use the
> snd_pcm_get_trigger_tstamp() call.

Because trigger_tstamp only gets updated in the trigger callback, when
the PCM is stopped, started, or paused.  I will have to check the code
to see what you use for the irq timestamp.

Lee



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: [Jackit-devel] irq handler top half timestamps

[Florian Schmidt]

On Thu, 16 Dec 2004 13:35:18 -0500
Lee Revell <rlrevell@joe-job.com> wrote:

> On Thu, 2004-12-16 at 17:33 +0100, tapas wrote:
> > Fons Adriaenssen wrote to me that he tried snd_pcm_get_trigger_tstamp(),
> > but he always got the same value back. Since the docs are rather sparse
> > i want to ask the alsa-devs about exactly how to use the
> > snd_pcm_get_trigger_tstamp() call.
> 
> Because trigger_tstamp only gets updated in the trigger callback, when
> the PCM is stopped, started, or paused.  I will have to check the code
> to see what you use for the irq timestamp.

Hi,

did you find something? Or does the api not have any provisions for this
yet?

Flo

-- 
Palimm Palimm!
http://affenbande.org/~tapas/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: [Alsa-devel] Re: irq handler top half timestamps

[Lee Revell]

On Mon, 2004-12-20 at 00:45 +0100, Florian Schmidt wrote:
> On Thu, 16 Dec 2004 13:35:18 -0500
> Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > On Thu, 2004-12-16 at 17:33 +0100, tapas wrote:
> > > Fons Adriaenssen wrote to me that he tried snd_pcm_get_trigger_tstamp(),
> > > but he always got the same value back. Since the docs are rather sparse
> > > i want to ask the alsa-devs about exactly how to use the
> > > snd_pcm_get_trigger_tstamp() call.
> > 
> > Because trigger_tstamp only gets updated in the trigger callback, when
> > the PCM is stopped, started, or paused.  I will have to check the code
> > to see what you use for the irq timestamp.
>
> did you find something? Or does the api not have any provisions for this
> yet?
> 

OK the interrupt handler calls snd_pcm_period_elapsed, which calls
snd_pcm_update_hw_ptr_interrupt, which calls snd_pcm_update_hw_ptr_pos.
snd_pcm_update_hw_ptr_pos does this (from alsa-kernel/core/pcm-lib.c):

151         pos = substream->ops->pointer(substream);
152         if (pos == SNDRV_PCM_POS_XRUN)
153                 return pos; /* XRUN */
154         if (runtime->tstamp_mode & SNDRV_PCM_TSTAMP_MMAP)
155                 snd_timestamp_now((snd_timestamp_t*)&runtime->status->tstamp, runtime->tstamp_timespec);

Here is snd_timestamp_now (from alsa-kernel/include/core.h):

464 static inline void snd_timestamp_now(struct timespec *tstamp, int timespec)
465 {
466         struct timeval val;
467         /* FIXME: use a linear time source */
468         do_gettimeofday(&val);
469         tstamp->tv_sec = val.tv_sec;
470         tstamp->tv_nsec = val.tv_usec;
471         if (timespec)
472                 tstamp->tv_nsec *= 1000L;
473 }

Note the FIXME.

So this timestamp should be OK for our purposes.  Note the pointer
callback is called before the timestamp is taken, so this will introduce
variable delay as the pointer callback is different in every driver and
requires accessing the PCI bus to read the pointer from the hardware.

The API function to get the timestamp is snd_pcm_status_get_tstamp,
defined in alsa-lib/src/pcm/pcm.c.

Lee



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: [Jackit-devel] irq handler top half timestamps

[Florian Schmidt]

On Sun, 19 Dec 2004 18:38:19 -0500
Lee Revell <rlrevell@joe-job.com> wrote:

> OK the interrupt handler calls snd_pcm_period_elapsed, which calls
> snd_pcm_update_hw_ptr_interrupt, which calls snd_pcm_update_hw_ptr_pos.
> snd_pcm_update_hw_ptr_pos does this (from alsa-kernel/core/pcm-lib.c):
> 
> 151         pos = substream->ops->pointer(substream);
> 152         if (pos == SNDRV_PCM_POS_XRUN)
> 153                 return pos; /* XRUN */
> 154         if (runtime->tstamp_mode & SNDRV_PCM_TSTAMP_MMAP)
> 155                 snd_timestamp_now((snd_timestamp_t*)&runtime->status->tstamp, runtime->tstamp_timespec);

I see. And all these calls have constant execution time?

> 
> Here is snd_timestamp_now (from alsa-kernel/include/core.h):
> 
> 464 static inline void snd_timestamp_now(struct timespec *tstamp, int timespec)
> 465 {
> 466         struct timeval val;
> 467         /* FIXME: use a linear time source */
> 468         do_gettimeofday(&val);
> 469         tstamp->tv_sec = val.tv_sec;
> 470         tstamp->tv_nsec = val.tv_usec;
> 471         if (timespec)
> 472                 tstamp->tv_nsec *= 1000L;
> 473 }
> 
> Note the FIXME.
> 
> So this timestamp should be OK for our purposes.  Note the pointer
> callback is called before the timestamp is taken, so this will introduce
> variable delay as the pointer callback is different in every driver and
> requires accessing the PCI bus to read the pointer from the hardware.
> 
> The API function to get the timestamp is snd_pcm_status_get_tstamp,
> defined in alsa-lib/src/pcm/pcm.c.

Hmm,

how is do_gettimeofday implemented? Is it based on the TSC? It seems it
is for X86 which has a TSC. into arch/i386/kernel/time.c also points out
that it is subject to adjustments due to NTP.

I suppose it would be better to get the TSC timestamp directly as Ingo's
patch produces for RP kernels. OTOH gettimeofday is a more general API
and i suppose it should provide the best timestamping mechanism a
platform can offer, right?

I might be talking out of my behind here though. As i don't know pretty
much anything about ALSA nor kernel internals..

Flo

-- 
Palimm Palimm!
http://affenbande.org/~tapas/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: [Alsa-devel] Re: irq handler top half timestamps

[Florian Schmidt]

On Mon, 20 Dec 2004 16:08:55 +0100
Florian Schmidt <mista.tapas@gmx.net> wrote:

> I see. And all these calls have constant execution time?

Oops, i should read more carefully. sorry.

Flo

-- 
Palimm Palimm!
http://affenbande.org/~tapas/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: [Jackit-devel] irq handler top half timestamps

[Lee Revell]

On Tue, 2004-12-21 at 02:30 +0100, Florian Schmidt wrote:
> On Mon, 20 Dec 2004 16:08:55 +0100
> Florian Schmidt <mista.tapas@gmx.net> wrote:
> 
> > I see. And all these calls have constant execution time?
> 
> Oops, i should read more carefully. sorry.
> 

Well, it would be interesting to measure the variance due to the trigger
callback in the driver.  Usually this just does a single inl() to read
the pointer from the hardware, then a bit of arithmetic (bytes_to_frames
or whatever).  I think the variance will be a function of PCI bus
contention.  It would be great to have some numbers, though.

Also for testing purposes it would be trivial to add another timestamp
mode to ALSA, where the timestamp is taken as soon as possible in the
interrupt handler, instead of doing it after getting the pointer from
the hw.

Lee 



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: [Alsa-devel] Re: irq handler top half timestamps

[Lee Revell]

On Sat, 2004-12-11 at 01:56 +0100, Florian Schmidt wrote:
> On Fri, 10 Dec 2004 16:01:48 -0500 Lee Revell <rlrevell@joe-job.com> wrote:
> > I don't really consider this new level very significant in practice
> > because it's fast and exactly the same for all devices.  IOW the
> > snd_pcm_period_elapsed timestamp should be good.  I don't think we need
> > to worry about the threaded ALSA IRQ case.
> 
> When exactly is snd_pcm_period_elapsed called? Is it called from the
> ALSA driver interrupt handler (excuse, if this question is stupid, i'm
> not too well versed (mildly speaking) when it comes to driver hacking)?
> Is it the first thing in the irq handling routine?

If the device supports interrupts at the period boundary like most sound
cards it's the only thing in the ALSA interrupt handler:

static void snd_emu10k1_pcm_efx_interrupt(emu10k1_t *emu, unsigned int status)
{
        snd_pcm_period_elapsed(emu->pcm_capture_efx_substream);
}

If the device uses a timer to generate interrupts at a fixed frequency
then you have to manually compare the frames processed to the period
size and call snd_pcm_period_elapsed if the period has indeed elapsed.

Lee




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: [Jackit-devel] irq handler top half timestamps

[Martijn Sipkema]

[...]
> > When exactly is snd_pcm_period_elapsed called? Is it called from the
> > ALSA driver interrupt handler (excuse, if this question is stupid, i'm
> > not too well versed (mildly speaking) when it comes to driver hacking)?
> > Is it the first thing in the irq handling routine?
> 
> If the device supports interrupts at the period boundary like most sound
> cards it's the only thing in the ALSA interrupt handler:
> 
> static void snd_emu10k1_pcm_efx_interrupt(emu10k1_t *emu, unsigned int status)
> {
>         snd_pcm_period_elapsed(emu->pcm_capture_efx_substream);
> }
> 
> If the device uses a timer to generate interrupts at a fixed frequency
> then you have to manually compare the frames processed to the period
> size and call snd_pcm_period_elapsed if the period has indeed elapsed.

(sorry, a bit off-topic)
Does that mean that ALSA will always have a large (relative to the interrupt
frequency) scheduling jitter for cards that interrupt at a fixed frequency?
Or is it possible to have ALSA return samples immediately after they become
available?


--ms



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: [Jackit-devel] irq handler top half timestamps

[Clemens Ladisch]

Martijn Sipkema wrote:
> > If the device uses a timer to generate interrupts at a fixed frequency
> > then you have to manually compare the frames processed to the period
> > size and call snd_pcm_period_elapsed if the period has indeed elapsed.
>
> Does that mean that ALSA will always have a large (relative to the interrupt
> frequency) scheduling jitter for cards that interrupt at a fixed frequency?

Yes, if the hardware periods don't exaclty match ALSA periods.
(Using e.g. snd-ymfpci at 48 kHz with periods of 256 samples shouldn't
introduce any additional jitter.)

> Or is it possible to have ALSA return samples immediately after they become
> available?

The ALSA API assumes constant-sized periods.  (Jack's Tascam USB
driver bypasses the ALSA API.)


HTH
Clemens



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: [Jackit-devel] irq handler top half timestamps

[Martijn Sipkema]

> > > If the device uses a timer to generate interrupts at a fixed frequency
> > > then you have to manually compare the frames processed to the period
> > > size and call snd_pcm_period_elapsed if the period has indeed elapsed.
> >
> > Does that mean that ALSA will always have a large (relative to the interrupt
> > frequency) scheduling jitter for cards that interrupt at a fixed frequency?
> 
> Yes, if the hardware periods don't exaclty match ALSA periods.
> (Using e.g. snd-ymfpci at 48 kHz with periods of 256 samples shouldn't
> introduce any additional jitter.)
> 
> > Or is it possible to have ALSA return samples immediately after they become
> > available?
> 
> The ALSA API assumes constant-sized periods.  (Jack's Tascam USB
> driver bypasses the ALSA API.)

Ah, I'll have a look at that; I was able to buy a Swissonic USB studio D for
a very good price and now I want low latency with this "bad" hardware. :)
I would be nice to have ALSA support non-constant periods (transfer is a
better term in that case I think).


--ms



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: [Alsa-devel] Re: irq handler top half timestamps

[James Courtier-Dutton]

On Mon, 20 Dec 2004 12:10:25 +0100 (MET), Clemens Ladisch
<clemens@ladisch.de> wrote:
> 
> The ALSA API assumes constant-sized periods.  (Jack's Tascam USB
> driver bypasses the ALSA API.)

Maybe we should add support for varying size periods. e.g. For when
resampling from 44100 to 48000.
I was thinking of maybe adding the "next_period_size" variable as one
of the returned variables from the copy_areas sections in the rate
plugin.

> HTH
> Clemens
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: [Alsa-devel] Re: irq handler top half timestamps

[Jaroslav Kysela]

On Thu, 9 Dec 2004, Lee Revell wrote:

> Doesn't ALSA already do this?  IIRC when you call snd_pcm_period_elapsed
> in the ALSA irq handler the PCM stream is timestamped.

Exactly. We need only use continuous (monotonic) timer source from 2.6 
kernels, because standard gettimeofday() might slip when time is corrected 
(from an NTP source, for example).

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/