Date: Fri, 25 Jul 1997 06:46:17 +0200 (MET DST) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: rhh@ct.picker.com (Randall Hopper) Cc: multimedia@FreeBSD.ORG Subject: Re: sb16 request Message-ID: <199707250446.GAA27161@labinfo.iet.unipi.it> In-Reply-To: <19970724113706.51706@ct.picker.com> from "Randall Hopper" at Jul 24, 97 11:36:47 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Luigi Rizzo: > |I am looking at the sb16 operation in full duplex using dual dma (one > |8-bit, the other 16-bit): > > |Which one fo the following approaches people prefers: > | > |1. always use 16-bit for play, 8-bit for record; ... to clarify: I am making the assumption that 16-bit data cannot be transferred using an 8-bit channel and vice-versa when using full-duplex. This might be a wrong assumption, in which case life is much easier since you can use high quality audio on both directions. > For the interface, can the 8-bit/16-bit under-the-hood be hidden? That is, to some extent, yes. But 8-bit is really poor quality and I'd rather use 16-bit (e.g. when converting from/to uLAW) if possible. > Also, I'm curious. For full-duplex, does the client open /dev/dsp with > O_RDWR instead of O_RDONLY and O_WRONLY, and then interleaved reads and > writes are both valid on that descriptor? That would be pretty simple. This is another, more general, issue. Right now, in the new sound driver, I am using only one descriptor, and either the client interleaves reads and writes, or it forks and then the two process can do i/o concurrently (I have two separate busy flags, one for reading the other for writing, and one 'global' busy flag to aviod two opens). However my final plan is to support up to two descriptors (i.e. opens) on the same device. That way you can settle a phone-type application with cat /dev/audio | rsh remotehost cat > /dev/audio & rsh remotehost cat < /dev/audio | cat > /dev/audio & which is quite nice (I have done it in the past using the Audioserver software on a DEC). The two-descriptors solution should not break anything (Amancio was concerned with backward compatibility). Cheers Luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707250446.GAA27161>