Messages in this thread | | | Date | Mon, 9 Jan 2006 23:20:43 +0000 | From | John Rigg <> | Subject | Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity |
| |
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/
| |