From owner-freebsd-multimedia  Fri Jul 18 08:28:36 1997
Return-Path: <owner-multimedia>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id IAA27906
          for multimedia-outgoing; Fri, 18 Jul 1997 08:28:36 -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 IAA27776
          for <multimedia@FreeBSD.ORG>; Fri, 18 Jul 1997 08:27:13 -0700 (PDT)
Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id QAA17750; Fri, 18 Jul 1997 16:13:17 +0200
From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Message-Id: <199707181413.QAA17750@labinfo.iet.unipi.it>
Subject: Re: sound and dma ...
To: hasty@rah.star-gate.com (Amancio Hasty)
Date: Fri, 18 Jul 1997 16:13:17 +0200 (MET DST)
Cc: multimedia@FreeBSD.ORG
In-Reply-To: <199707181503.IAA05006@rah.star-gate.com> from "Amancio Hasty" at Jul 18, 97 08:03:18 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-multimedia@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 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