--pgp-sign-Multipart_Fri_Dec__3_23:36:14_2004-1
Content-Type: text/plain; charset=US-ASCII

I'm planning to add the following capabilities to the audio
framework:
 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.
	mulaw_to_ulinear16_le()
	mulaw_to_ulinear16_be()
	mulaw_to_slinear16_le()
	mulaw_to_slinear16_be()
	mulaw_to_ulinear8()
	mulaw_to_slinear8()
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
	  |
	hardware

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 hauN.org> <kent at NetBSD.org>

--pgp-sign-Multipart_Fri_Dec__3_23:36:14_2004-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (NetBSD)

iQEVAwUAQbB54n7t9398iwLqAQIJHAf/WU/DCt5OL9CtFw74aouPRxERu/iWCekU
QOwIc8V8n3Wnb9GiDRlb3SAG1b+CKl6fxHgMAlvE7RsT07ntkpofAxzVu390gEyj
GNRHjbd+DTpgc2D9MgSt9+A4ajdpuAHhZhAbpYYhZhqxvtw7k5Crq2Dzp24rQVP3
b83nvNHy8IS021tD8bUftkQOaDTCag7PrAdwQ5sU+MfmCH2cmZ2HVa/LlzMhBoQX
ZQmhXzn/rgWvzlAdoXERiwZso5UcdBla5E4LldMUqTRnKz1YzXXXNp0KYJDvPv3b
BE15wxJE8LcJtKZPIPaaCQjeVmWt8LzxfQ8d0LHM3vaiKevru/D+kg==
=JLyw
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Fri_Dec__3_23:36:14_2004-1--