From owner-freebsd-multimedia  Thu Jul 24 08:44:36 1997
Return-Path: <owner-freebsd-multimedia>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id IAA05886
          for multimedia-outgoing; Thu, 24 Jul 1997 08:44:36 -0700 (PDT)
Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id IAA05873
          for <multimedia@FreeBSD.ORG>; Thu, 24 Jul 1997 08:44:30 -0700 (PDT)
Received: from ct.picker.com by whqvax.picker.com with SMTP;
          Thu, 24 Jul 1997 11:39:24 -0400 (EDT)
Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1)
	id AA04499; Thu, 24 Jul 97 11:39:21 EDT
Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4)
	id LAA21713; Thu, 24 Jul 1997 11:37:06 -0400
Message-Id: <19970724113706.51706@ct.picker.com>
Date: Thu, 24 Jul 1997 11:37:06 -0400
From: Randall Hopper <rhh@ct.picker.com>
To: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Cc: multimedia@FreeBSD.ORG
Subject: Re: sb16 request
References: <19970724071551.54552@ct.picker.com> <199707241343.PAA26156@labinfo.iet.unipi.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.76
In-Reply-To: <199707241343.PAA26156@labinfo.iet.unipi.it>; from Luigi Rizzo on Thu, Jul 24, 1997 at 03:43:15PM +0200
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):

Hey, cool!

 |Which one fo the following approaches people prefers:
 |
 |1. always use 16-bit for play, 8-bit for record;
 |2. always use 16-bit for record, 8-bit for play;
 |3. allocate the 16-bit channel to the first type of request (read or
 |   write) and use the 8-bit channel for the other one.
 |
 |or
 |
 |4. define a new ioctl to chose which channel gets the 16-bit dma and
 |   which one gets the 8-bit dma, with some default camong those
 |   described before.

4. sounds like the most flexible to me.  Selectable, but with a default.

For the interface, can the 8-bit/16-bit under-the-hood be hidden?  That is,
the client opens dsp and selects 8-bit or 16-bit, and the recorded samples
fed to the driver as well as the played samples read back from the driver
are both in that format.  I.e. have the driver convert the 8-bit to 16 if
16-bit selected, or the 16-bit down to 8 if 8-bit selected.  I'd be
concerned about driver overhead with this suggestion, but there's no math
involved and it's a very cheap conversion so it might be worth it to
abstract implementation tricks under the hood.  Would make it easier to use
existing full-duplex apps.

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.

 |P.S. I don't have an SB16 so I will then need someone to help with
 |testing...

Be glad to.  Just let me know.

Randall