Date: Mon, 31 Jul 2000 17:53:03 +0100 From: "Cameron Grant" <gandalf@vilnya.demon.co.uk> To: "Luoqi Chen" <luoqi@watermarkgroup.com>, <multimedia@FreeBSD.ORG>, <sreid@sea-to-sky.net> Subject: Re: State of sound support in 4.1-R ? Message-ID: <007501bffb0f$ce094b20$0504020a@haveblue> References: <200007311628.e6VGSrB23755@lor.watermarkgroup.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > actually, the comment for sndmmap() is wrong. the oss spec defines the
mmap
> > protection flags as the method of selecting the read or write buffer so
we
> > comply with that, but for a vm issue.
> >
> Then the spec has fundamental problems: in our vm systems, a vm object (in
> our case, the sound device) and an offset within this object uniquely
> identifies a page, protection is just an attribute of this page, the
content
> of this page doesn't change magically because you switch from read to
write.
yes. fortunately, i know of no application which opens /dev/dsp readwrite
and then tries to mmap the read buffer.
> > mmap prior to setting the format should work, if it doesn't i'd be
> > interested in seeing the code that is trying to do this and failing.
> >
> It goes like this, the native format of my soundcard is 16bit, quake opens
> /dev/dsp, which supposed to be 8bit, mmaps it, and then sets format to
16bit.
sb16 isa?
hm, i'd not thought about that. one solution would be to use /dev/dspW.
-cg
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?007501bffb0f$ce094b20$0504020a>