Subject: Ideas on the audio framework
To: None <>
From: TAMURA Kent <>
List: tech-kern
Date: 12/03/2004 23:36:18
Content-Type: text/plain; charset=US-ASCII

I'm planning to add the following capabilities to the audio
 A. Audio converter pipeline
 B. In-kernel audio mixing

A. Audio converter pipeline

The goals are:
* add capability to run multiple audio stream converters between
  read(2)/write(2) and the hardware buffer
* unify interfaces of playing converters and recording converters
* represent aurateconv as a converter

In the current framework, a hardware driver can set just one
converter to audio_params::sw_code.  So, a sw_code
implementation have to do everything of required conversions.

We have six mulaw_to_something() functions in sys/dev/mulaw.c.
We can get the same results as theirs by combinations of
mulaw_to_slinear16_le(), swap_bytes(), change_sign16_le(), and
linear16_to_linear8_le().  We can reduce such redundant code by
introducing the audio converter pipeline.

The current sw_code interface is curious.  The third parameter
is the output size for playing converters, and the input size
for recording converters.  Of course, playing converters can not
be used for recording.  A hardware driver needs to set correct
values to audio_params::factor and factor_denom though they are
fixed values for a converter.

If aurateconv is repreesnted as a converter and the converter
pipeline is implemented, we can easily realize sampling rate
conversion for ADPCM-only hardware like sys/arch/x68k/dev/vs.c.
	ADPCM stream
	  |  [ADPCM -> PCM converter]
	PCM stream
	  |  [aurateconv]
	PCM stream
	  |  [PCM -> ADPCM converter]
	ADPCM stream

What is required?
  - define new converter interface
  - rewrite all sw_code implementations for the new interface
  - parameters of audio_hw_if::set_params() may be changed
  - ...

B. In-kernel audio mixing

The goals are:
* /dev/audioN can be opened by multiple processes, and
* audio streams written by the processes are mixed in the kernel
  and played with a single hardware.

It would not be hard to realize the audio mixing if we had the
audio converter pipeline and the device cloning.  To mix audio
streams, they must be the single PCM format and the single
sampling rate.  The audio converter pipeline would help it.


Any comments?

I have a concrete design of the audio converter pipeline, and
will start implementation soon.

TAMURA Kent <kent_2004 at> <kent at>

Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

Version: GnuPG v1.2.4 (NetBSD)