Subject: kern/9087: audio mmap(2) interface not entirely clear
To: None <firstname.lastname@example.org>
From: None <email@example.com>
Date: 12/30/1999 20:45:46
>Synopsis: audio mmap(2) interface not entirely clear
>Responsible: kern-bug-people (Kernel Bug People)
>Arrival-Date: Thu Dec 30 20:45:00 1999
>Originator: Dave Sainty
Dynamic Technology Services and Products Ltd (NZ)
>Release: Recent current
System: NetBSD tequila.dave.dtsp.co.nz 1.4P NetBSD 1.4P (TEQUILA) #0: Thu Dec 30 01:04:54 NZDT 1999 firstname.lastname@example.org:/vol/tequila/userB/u2/NetBSD-current/src/sys/arch/i386/compile/TEQUILA i386
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.
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!? :)
Well, it needs to be confirmed exactly what the interface should
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.