From alsa-devel-owner@alsa.jcu.cz  Fri Nov 27 13:52:23 1998
Received: from entry.jcu.cz (IDENT:perex@entry.jcu.cz [160.217.1.111])
	by marvin.jcu.cz (8.9.1a/8.9.1) with SMTP id NAA24162;
	Fri, 27 Nov 1998 13:50:18 +0100
Date: Fri, 27 Nov 1998 13:50:18 +0100 (CET)
From: Jaroslav Kysela <perex@jcu.cz>
To: meme <meme@interzone.org>
cc: alsa-devel@jcu.cz
Subject: Re: Virtual array of audio devices. Filters etc. ?
In-Reply-To: <Pine.LNX.4.04.9811251417310.26212-100000@soma.interzone.org>
Message-ID: <Pine.LNX.3.96.981127120302.4886A-100000@entry.jcu.cz>
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

On Wed, 25 Nov 1998, meme wrote:

> 
> 
> On Wed, 25 Nov 1998, Jaroslav Kysela wrote:
> 
> > 
> > PCM stream ---> Audio Server -> conversion -> filters -\
> > PCM stream ---> Audio Server -> conversion -> filters ---> Kernel driver
> > PCM stream ---> Audio Server -> conversion -> filters -/
> > 
> 
> Mmmm...  this sounds reasonable.  The problem with Cubase VST, CoolEdit or
> any other software like that is DirectX for the plugins and DSP on the
> recording hardware.  I would really like to see linux as a recording
> platform, even justa HD based non-linear recorder/editor.  Event
> Electronics weren't willing to give me specs for their card, but I'll keep
> looking into others.  Maybe Ensoniq/Emu's PARIS hardware?!  We'll see.
> 
> Fileter aren't much use to me if they aren't real-time.  This requires
> (possibly) access to the DSPs while recording/mixing.  Cubase and CoolEdit
> aren't necesssarily real-time either.
> 
> PCM Stream ---> Audio Server ---> DSP with filters --> conversion -->
> disk.
> 
> Keep in mind that to be competitive you need to be able to have 8 24-bit
> 48-96Khz streams recording/aux sending/effecting at once.  PARIS does it,
> but that's because there are 6 killer DSPs per PCI card.
> 
> Ideally, the implementations should be abstract enough to allow 4
> soundcards to record a 4 channel mix as well as a Layla/Gine/Darla to
> behave similarly addressable audio channels from the user software.
> 
> Effects need to be routable.  If I have a couple of AudioPCI cards, I need
> to use my CPU to do the effects (i realize this might not be real-time,
> but that's not the point at the moment)  If I have something with a DSP,
> then there needs to be an abstraction layer of sorts (needs to be there
> anyway, if you ask me) that can reroute the audio stream and the effect
> through the DSP.  In either case, I think the architecture of the SW
> should be such that it is routed through dsp /dev entries with effects
> whether or not there are dsps present.
> 
> More than anything I want to be able to power up my linux box and record a
> show on the HD without needing anything more than one of those LCD
> displays and a keypad to set the initial level and provide a meter
> readout.  hehehe.

I read carefully your requirements. I should say that I'm new in professional
audio. Looks like you need complete ABU and DSP support. Correct me if I'm
wrong in some facts:

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)
  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

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

Terminology: PCM stream - PCM data in user space
             application/kernel - boundary between application and kernel
                                  driver
	     preprogrammed DSP - DSP which is over some driver interface
                                 programmed before use

If you look to articles 1) and 2) - they can be implemented with staying
ALSA PCM interface. Lowlevel driver can simply return to application data
after DSP processing.

Article 3) will require some new ALSA devices which will allow
send/receive PCM data to DSP processor. Maybe these devices should be used
for DSP programming for standard PCM interface, too.

I see in your document something like data routing.. Data routing
(except routing in articles 1) and 2)) should be probably fully
implemented in user space (application).

Above described interface will allow use for example this routing:

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]

Above example isn't probably good for realtime audio data processing, but
if lowlevel driver will allow serialize DSP effects, we can eventually do 
this processing in realtime.

OK. I can try do some DSP interface proposal if I'm not wrong in above
text, but don't expect that effects should be set for all DSPs in same
way. I'll try do some abstract layers only for common things and some
universal interface to setup specific named parameters.

I welcome any feedbacks...

						Jaroslav

-----
Jaroslav Kysela <perex@jcu.cz>
Academic Computer Centre, University of South Bohemia
Branisovska 31, C. Budejovice, CZ-370 05 Czech Republic


