NetBSD Problem Report #9087

Received: (qmail 16906 invoked from network); 31 Dec 1999 04:43:32 -0000
Message-Id: <19991231034840.13269.qmail@mailhost.dave.dtsp.co.nz>
Date: 31 Dec 1999 03:48:40 -0000
From: dave@dtsp.co.nz
Reply-To: dave@dtsp.co.nz
To: gnats-bugs@gnats.netbsd.org
Cc: dave@dtsp.co.nz
Subject: audio mmap(2) interface not entirely clear
X-Send-Pr-Version: 3.95

>Number:         9087
>Category:       kern
>Synopsis:       audio mmap(2) interface not entirely clear
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Dec 30 20:45:00 +0000 1999
>Closed-Date:    
>Last-Modified:  
>Originator:     Dave Sainty
>Release:        Recent current
>Organization:
Dynamic Technology Services and Products Ltd (NZ)
>Environment:
System: NetBSD tequila.dave.dtsp.co.nz 1.4P NetBSD 1.4P (TEQUILA) #0: Thu Dec 30 01:04:54 NZDT 1999 dave@tequila.dave.dtsp.co.nz:/vol/tequila/userB/u2/NetBSD-current/src/sys/arch/i386/compile/TEQUILA i386


>Description:
	This problem appears in the eso (ESS Solo-1) driver, but I think may
	be in others also.

	The problem is: What size is the buffered mmap()'d area?

	According to audio(4), this area should be the full buffer size.  But
	this does not appear to be enforced, and indeed it appears that
	sys/dev/audio.c will intruct the driver to start playing with a
	possibly smaller buffer at open time.

	In the eso driver this is particularly apparent because the output
	buffer size is 65535 bytes, generally not divisible by the fragment
	size.  The mmap()'ed area is actually the buffer size rounded down to
	the last fragment boundary.  But I think the problem may be triggered
	in other drivers by using appropriate fragment sizes.

	"eap" and "sv" have apparently cut-and-pasted code for mappage().
	Even isa/sbdsp.c looks like its mappage() is too simplistic.

>How-To-Repeat:
	Play quake2 with an ESS Solo-1 card :)

	Any application that follows audio(4) and assumes the buffer size will
	be the buffer_size may lose (unless the set the fragment
	appropriately, but what if the buffer size is prime!? :)

>Fix:
	Well, it needs to be confirmed exactly what the interface should
	be...

	The problem can be fixed in each driver, or possibly fixed in audio.c
	by reissuing a trigger_output() at mmap() time if required.  The
	latter may be simpler, but may have unfortunate side effects in that
	the trigger_output() interface includes a block size that may not
	divide the buffer size evenly (which may surprise some drivers).

	If mappage() is to be fixed, it should be documented in audio(9).
	Probably it should be fleshed out in audio(9) anyway, so it's clear.
>Release-Note:
>Audit-Trail:
>Unformatted:

Home	PR Database Search