On Sun, Jan 11, 2004 at 04:02:33PM +1100, matthew green wrote:
   > however, IMO, there should not be any code to mix audio in *software*
   > in the kernel...
   
   There's already the facility for software rate conversion in the
   kernel, that's used by some drivers where the hardware doesn't support
   common sample rates. Using software mixing to hide the lack of
   hardware mix support seems like a pretty similar case, and arguably
   *less* expensive for most uses than rate-adaption. (It also might be
   used after N opens on limited hardware, eg eap supports 2 h/w voices).

rate adaption is _way_ more expensive than flipping a sign and/or
changing the size of a sample.  simple mixing is even more expensive
than that, and mixing may need both rate adapation _and_ other
adjustments made before the final mixing step... compare dev/auconv.c
to dev/aurateconv.c.

(BTW, eap support of 2 audio devices is ... poor at best.  if you
actually use audio1, audio0's input becomes warbled... it may stop
doing it some time after you stop using audio1 - but that irrelevant
to this discussion.)
   
   It seems to me that "neither or both" of these facilities belong in
   the kernel, and that the choice depends on driver/hardware capability
   and user preference.

could be.  i actually stole a bunch of the kernel auconv.c code for
audio*(1).  it's necessary to be able to output in an arbitrary (ie,
user defined) format...but i've not needed the aurateconv code yet.

from what i gather, aurateconv really exists in the kernel to support
devices that don't support rates that audio(4) says will exist.  eg,
the default 8000hz setting.


the main reason i'm not wanting this code in the kernel is really just
"don't put code in the kernel that can be in userland".

what do other systems do?


.mrg.