Re: [alsa-devel] Re: [linux-audio-dev] laaga, round 2

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [alsa-devel] Re: [linux-audio-dev] laaga, round 2
From: Abramo Bagnara (abramo_AT_alsa-project.org)
Date: Tue May 15 2001 - 18:18:57 EEST


Paul Davis wrote:
>
> I wrote:
>
> >> context switch costs that we've been discussing, the cost of zeroing
> >> memory goes down more or less linearly with processor speed (helped
> >> along by RAM speed, which is increasing much more slowly). Because of
> >> this, we should consider the cost to zero a buffer to be an
> >> essentially vanishing item in the overall operation of an audio
> >> system.
>
> Abramo replied:
>
> >I think you should have benchmarked this statement before to write it
> >;-)
>
> I have. Re-read what I wrote. I know that there are real costs of
> zeroing the buffer and using "+=". But that cost is almost linear with
> CPU speed. You speak often of planning for the future. The cost right
> now is quite manageable, and will only get smaller. The benefit of
> adopting this model is immense in terms of simplicitly. To design a
> system in which we create complexity to solve a *vanishing* problem
> seems foolhardy to me.
>
> Contrast this to the costs of IPC, which do not scale linearly with
> CPU speed, and will never really vanish until we are all using 64 bit
> operating systems that use a single address space (i.e. the TLB is
> never flushed). Such operating systems do exist, but only in CS and
> R&D departments.

I don't want you to think I disagree: I've only commented your statement
with some actual numbers to know the cost on low end machine... and I've
to say that I've still some doubts:

If plugin is used outside a realtime constraint performance impact might
become noticeable (suppose we want to handle 1E6 samples per second).

what about normalization?
who does it?
it's formally correct to do it only on last destination (hw, file,
etc.)?

Complexity impact is tiny: we may use the same source file with a macro
that is responsible for sample storing.

-- 
Abramo Bagnara                       mailto:abramo_AT_alsa-project.org

Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy

ALSA project http://www.alsa-project.org It sounds good!


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue May 15 2001 - 18:40:34 EEST