On Tue, Apr 20, 2010 at 09:34:22PM +0200, frantisek holop wrote: > re aucat et al, i was wondering, > will it ever make /etc/rc.conf?
yes. > for me, the ocassional music listener > plus movie watcher, what are the > obvious reasons i should be running the > aucat sound server? it's the only way to really support hardware. seriously. there are some conversion routines in the kernel to help when hardware does not support parameters a program wants to use, but it is an incomplete set, and it is buggy. the conversions were added on as an afterthought. well, I don't know how else to explain the fact that recording conversions were not actually used and the multiple places where the conversion factor needed to be taken into account but wasn't. most of that has been straightened out, but therer can still be issues, especially with OSS applications, because of the OSS spec says to set the block/buffer size first. this means the block size gets set before the final expansion factor is known. couple that with the fact that drivers on OpenBSD used to always default to mono mulaw, which in any cases needs an expansion factor, and it is impossible to set/know the blocksize, which can lead to hard to understand (much less fix) problems. imo, the in-kernel conversions are the #1 reason OpenBSD audio feel into disrepair. they allowed people to do 'cat file.au > /dev/audio' but broke many, many applications. > there has been tons of changes since > aucat graduated into the source tree, > someone knowledgeable might do a nice > writeup (maybe on undeadly?) what advanced > audio scenarios have now became available > because of this technology. > > perhaps this seems like a stupid mail, > but i am not really an audio person outside > the simple audio(4) consuming but i have > been making circles around aucat for a while now > not really sure how could i take advantage of it. > > help us poor audio illiterates to appreciate > aucat in its fullest potential :] > > -f > -- > jury: a group chosen to decide who has the best lawyer. -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
