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

[John Rigg <ad@sound-man.co.uk>]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/