Date: Fri, 15 Apr 2005 09:53:35 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: Julian Elischer <julian@elischer.org> Cc: Mathew Kanner <mat@cnd.mcgill.ca> Subject: Re: de-dma uaudio Message-ID: <20050415095335.46kkjh7q4gkwook0@netchild.homeip.net> In-Reply-To: <425ED3F0.70603@elischer.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
--
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
The problem that we thought was a problem was, indeed,
a problem, but not the problem we thought was the problem.
-- Mike Smith
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050415095335.46kkjh7q4gkwook0>