From owner-freebsd-multimedia  Fri Jul 18 09:33:25 1997
Return-Path: <owner-multimedia>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id JAA01750
          for multimedia-outgoing; Fri, 18 Jul 1997 09:33:25 -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 JAA01739
          for <multimedia@FreeBSD.ORG>; Fri, 18 Jul 1997 09:33:18 -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 JAA05399;
	Fri, 18 Jul 1997 09:30:57 -0700 (PDT)
Message-Id: <199707181630.JAA05399@rah.star-gate.com>
To: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
cc: multimedia@FreeBSD.ORG
Subject: Re: sound and dma ... 
In-reply-to: Your message of "Fri, 18 Jul 1997 16:13:17 +0200."
             <199707181413.QAA17750@labinfo.iet.unipi.it> 
Date: Fri, 18 Jul 1997 09:30:57 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
Sender: owner-multimedia@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

No problem;specially, since , the dma subsystem is so complex for
just playing audio --- I think is amazing . Hopefully, with PCI
things will get better because the complex buffering scheme is
really about reducing latency to the sound card.

	Have fun!
	Amancio
>From The Desk Of Luigi Rizzo :
> > Hi,
> > The problem with eliminating functionality like is that 
> > it will render us uncompatible with the linux or with linux
> > apps.
> > 
> > SOUND_PCM_SUBDIVIDE is really use for setting the buffer size and
> > to provide multiple buffers. 
> > 
> > The sound driver generates N number of buffers based upon the size
> > of its pool and the the size of a buffer. The intent is eliminate
> > clicks. There is also buffering done on sound cards such as the
> 
> right, I was mistaken... at a more careful reading the code seems
> to generate a number of sub-buffers as you mention, and the
> 'SUBDIVIDE' ioctl is only of use if one wants to force the driver
> to split the available buffer space in more pieces than it would
> do using the normal heuristics. In this view (and especially, now that
> I understand _how_ it works), I can probably keep the current code.
> 
> Note however that my idea was _not_ to kill the ioctl, just make it a
> NOP.
> 
> 	Cheers
> 	Luigi
>