Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity

John Rigg
2006-01-09T23:20:43Z

On Mon, Jan 09, 2006 at 01:58:00PM -0800, David Lang wrote:
> On Mon, 9 Jan 2006, René Rebe wrote:
>
> >On Monday 09 January 2006 16:10, Hannu Savolainen wrote:
> >
> >>>>I don't think so. The library can do such conversions (and alsa-lib
> >>>>does)
> >>>>quite easy. If we have a possibility to remove the code from the kernel
> >>>>space without any drawbacks, then it should be removed. I don't see any
> >>>>advantage to have such conversions in the kernel.
> >>>
> >>>Also, when the data is already available as single streams in a
> >>>user-space
> >>>multi track application, why should it be forced interleaved, when the
> >>>hardware
> >>>could handle the format just fine?
> >>Because the conversion doesn't cost anything. Trying to avoid it by
> >>making the API more complicated (I would even say confusing) is extreme
> >>overkill.
> >
> >Since when doesn't cost convesion anything? I'm able to count a lot of
> >wasted
> >CPU cycles in there ...
>
> if the data needed to be accessed by the CPU anyway it's free becouse
> otherwise the CPU would stall waiting for the next chunk of memory. you
> can do quite a bit of work on data in cache while you are waiting for the
> next cache line to load.
>
> in this same way, checksumming a network packet is free if the CPU needs
> to copy the data anway, it only costs something if the data could bypass
> the CPU.

Yes, but the CPU has plenty of other work to do. The sound cards that
would be worst affected by this are the big RME cards (non-interleaved) and
multiple ice1712 cards (non-interleaved blocks of interleaved data),
which AFAIK are the only cards capable of handling serious professional audio.
This could represent 48 or more channels of 96kHz audio, which
doesn't leave a lot of spare CPU capacity for running X, for example.

John