Date: Fri, 15 Apr 2005 01:14:35 -0700 From: Julian Elischer <julian@elischer.org> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: Mathew Kanner <mat@cnd.mcgill.ca> Subject: Re: de-dma uaudio Message-ID: <425F77EB.7080902@elischer.org> In-Reply-To: <20050415095335.46kkjh7q4gkwook0@netchild.homeip.net> References: <20050410195645.GA2178@cnd.mcgill.ca> <20050414.021552.343134310.kazuhito@ph.noda.tus.ac.jp> <20050413172534.GF2178@cnd.mcgill.ca> <20050414161546.kwroviadwsw8k0w0@netchild.homeip.net> <425ED3F0.70603@elischer.org> <20050415095335.46kkjh7q4gkwook0@netchild.homeip.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexander Leidinger wrote: > Julian Elischer <julian@elischer.org> wrote: > >> The low hardware layer already does DMA to move data out of the >> hardware to memory. The data gets copied from the user layer to an >> intermediate >> buffer and from there to the DMA buffers. There is no need to allocate >> DMA capable >> buffers for the intermediate layer. > > > I understand this as: > userland-mem -> kernel-mem -> dma-able-mem -> hardware > > So there's no zero-copy behavior? > userland-mem -> in-kernel-dma-able-mem -> hardware > or > userland-mem -> if(is_dmaable(userland-mem)) -> hardware > else -> in-kernel-dma-able-mem -> hardware > > While the amount of memory used as a sound buffer isn't that much for > todays > standards, it's still a memory transfer operation which could be avoided. I > don't know how much it would affect the latency (or if it affects it at > all), but not doing things which aren't necesssary/beneficial is always a > win (in some way) in my experience. > > Bye, > Alexander. > no-one is saying that it can't be optimised.. try follow a read command from a ugen fd all the way to the hardware.. it's just not something we've spent time to do.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?425F77EB.7080902>