From alsa-devel-owner@alsa.jcu.cz  Sat Nov 28 03:09:55 1998
Received: from soma.interzone.org (IDENT:500@[209.181.227.108])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id DAA26244
	for <alsa-devel@jcu.cz>; Sat, 28 Nov 1998 03:09:19 +0100
Received: from localhost (meme@localhost)
	by soma.interzone.org (8.8.7/8.8.7) with ESMTP id UAA29785
	for <alsa-devel@jcu.cz>; Fri, 27 Nov 1998 20:09:12 -0600
Date: Fri, 27 Nov 1998 20:09:12 -0600 (CST)
From: meme <meme@interzone.org>
To: alsa-devel@jcu.cz
Subject: Re: Virtual array of audio devices. Filters etc. ?
In-Reply-To: <Pine.LNX.3.96.981127120302.4886A-100000@entry.jcu.cz>
Message-ID: <Pine.LNX.4.04.9811271932310.29756-100000@soma.interzone.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list


First off, thanks for the response.  Don't spend too much time thinking
about this since I believe I'm still some way off from figuring out the
details.  All I'm trying to do is show the possibilities...  So no worries
or hurries, please.

On Fri, 27 Nov 1998, Jaroslav Kysela wrote:
> ABU interface (digital professional audio connection between components):
> 
>   ALSA already supports:
> 	- rate up to 96kHz
> 	- 16-bit samples
>   ALSA doesn't support at this time (but interface should be easy extend):
> 	- above 16-bit wide samples (up to 24-bit)

Ok, that's good.  From what I know of  digital professional recording, the
current high end is 24bit/96 Khz, but that is technically still lacking.
(This all depends on hardware which supports this, of course).  Recording
at 24bit/96Khz and playing it back is good enough to fool the human ear
into thinking that it is listening to analog.

In the professional recording world, there are effects and filters which
need to be applied of course.  Theoretically, applying these causes some
degredation of quality, which in turn yields less than analog fooling
abilities of 24/96.  The ideas being discussed are 32/96 recording.  It is
redundant for just recording, but it allows the application of 24-32 bit
effects to a sample, and once it has been processed, it will still be good
enough to go to 24/96 undamaged.  I'm not sure I'm making myself clear.
The extra bits are there only to be skewed by the effects, thus leaving a
more than clean 24 bit sample to come out the other end.

>   I don't know:
> 	- maximum channels which should be over this interface transferred?
> 	- maybe this isn't very important - ALSA have 32-bit variable for
>           channel count

Again, this limitation will start with the hardware.  Ensoniq PARIS (6
ESP-2 DSP's per PCI card) allows for 16 24/48 channels (in or out) per PCI
card.

> 
> DSP interface:
> 
> Seems for me that you require three ways how can be HARDWARE DSP's used:
> 
> 1) PCM stream -> application/kernel -> preprogrammed DSP -> playback device
> 2) record device -> preprogrammed DSP -> kernel/application -> PCM stream
> 3) PCM stream -> application/kernel -> preprogrammed DSP -> 
> 					kernel/application -> PCM stream
> 
> record device -> DSP 1 -> kernel/application -> application/kernel ->
> DSP 3 -> kernel/application -> user space DSP ->
> [ application/kernel -> DSP 2 -> playback device ] or
> [ application/kernel -> DSP 2 -> kernel/application -> disk file]
> 
Wow... I see.  I believe that #3 isn't quite necessary since the PCM
stream could be manipulated in the application directly in that case, so
no worries there.  I have to do a little more research into how some of
the hardware DSP's are controlled.  Perhaps we could treat them as a
different entity altogether.  

The particular function of the DSP varies in realtime, so for example:
The microphone and 24/48 are purely arbitrary at the moment...

1) microphone (or other analog input) --> 24/48 A/D converter -->
effect(s) --> kernel/application --> PCM Stream

2) analog input --> 24/48 A/D conv. --> effect(s) --(fork)
     --> 24/48 D/A conv. --> to amp/monitors/etc.
and  --> kernel/application --> PCM Stream

In this way, the "effects" could be treated as a seperate entity
altogether and could be controlled from the application level through some
other driver(s).  (i.e.  a parametric equalizer knob(s) in the software
would manipulate the DSP directly, being completely transparent to the act
of recording)

#2 above is what would allow everything to remain real-time and "live"
You could use a gate/compressor on a vocal both on stage and while
recording the act.

One limit of the above, is that it doesn't allow for the possibility of
hostbased processing of the effects (everything, including A/D D/A and
effects are taking place on hardware on or past the PCI bus)

This is where your #3 above comes into play.
Instead of integrating the DSP into ALSA directly, the pre-programmed DSP
above could beaccess as a VDSP through whatever scheme is developed for
accessing the hardware DSP's. 

The turning of a know on-screen adding and reducing reverb ideally takes
place as you are listening to the music/track.

I hope I make at least a little bit of sense.  And again, this isn't high
priority by any means, but perhaps a few of our heads can work out a
brilliant architecture.

-m

PS I'm listening to the Ghost in the SHell soundtrack at the moment.


