From owner-freebsd-multimedia  Thu Jul 24 22:47:24 1997
Return-Path: <owner-freebsd-multimedia>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id WAA15703
          for multimedia-outgoing; Thu, 24 Jul 1997 22:47:24 -0700 (PDT)
Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id WAA15698
          for <multimedia@FreeBSD.ORG>; Thu, 24 Jul 1997 22:47:21 -0700 (PDT)
Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id GAA27161; Fri, 25 Jul 1997 06:46:18 +0200
From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Message-Id: <199707250446.GAA27161@labinfo.iet.unipi.it>
Subject: Re: sb16 request
To: rhh@ct.picker.com (Randall Hopper)
Date: Fri, 25 Jul 1997 06:46:17 +0200 (MET DST)
Cc: multimedia@FreeBSD.ORG
In-Reply-To: <19970724113706.51706@ct.picker.com> from "Randall Hopper" at Jul 24, 97 11:36:47 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-multimedia@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 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