From owner-freebsd-multimedia  Thu Jul 24 23:24:43 1997
Return-Path: <owner-freebsd-multimedia>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id XAA16954
          for multimedia-outgoing; Thu, 24 Jul 1997 23:24:43 -0700 (PDT)
Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA16949
          for <multimedia@FreeBSD.ORG>; Thu, 24 Jul 1997 23:24:41 -0700 (PDT)
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1])
	by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id XAA17813;
	Thu, 24 Jul 1997 23:23:35 -0700 (PDT)
Message-Id: <199707250623.XAA17813@rah.star-gate.com>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
cc: rhh@ct.picker.com (Randall Hopper), multimedia@FreeBSD.ORG
Subject: Re: sb16 request 
In-reply-to: Your message of "Fri, 25 Jul 1997 06:46:17 +0200."
             <199707250446.GAA27161@labinfo.iet.unipi.it> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 24 Jul 1997 23:23:34 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
Sender: owner-freebsd-multimedia@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>From The Desk Of Luigi Rizzo :
> > 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

Yes , it break existing solutions and it does make porting of other
sound apps from traditional sound api such as from sgi, sun or hp 
harder . If you want to multiplex sound streams then I suggest people
do it via some mechanism such as NCD's Network audio  . Last but not
least we will not be compatible with the linux audio ioctl api and 
at least to me that is far more important given that the group as whole
is not into writing sound apps.

Do whatever you can with the SB thingies we know its limitations if
people want better quality we can then recommend superior sound 
cards. 
	Amancio