PROPOSAL: Layer Signal Processing Architecture

PROPOSAL: Layer Signal Processing Architecture

[Ilya D]

Hello.

I have a proposal for this Layered Model,
which would allow implementation of new audio interfaces with DSP cores,
with cross-platform compatibility and audio networking in mind.

it would be a sort of OSI for signal processing, but with some extra
stuff to it, such as a common language (library) for hardware programming.

it's not to replace ALSA, but just to bring a different approach for
design engineers of professional audio applications.
we all know that these days a lot manufactuares chose Linux
for their Mixing Consoles (such as Midas, Lawo, Calrec and others),
also other products use Linux, but there might be only a few who use
ALSA (as far as i could find out there rather NONE in pro-audio Linux devices).

Linux runs on devices such as Blackfin and OMAP, which have DSP cores,
but the interface is device-specific, hence low-level.

ALSA had been designed for conventional sound-cards (largely) also there
drivers for RME, DigiGram and other pro-interfaces,
but the hardware is still proprietary and it isn't quite flexible.

The idea is to bring new concepts to the world, well not 100% new,
but new in a way. One of these would be to implement an "open-source"
audio processor interface of a kind.
It would have configurable channel strips with (multi-band EQ and dynamics).

Another motivating factor is upcomming completition of AVB ethernet
standard from IETF/IEEE, there had been no publicaly avaliable code
for this, nor i could find any discussions of how it could be
implemented in Linux. However i have contact with a professor Richard
Foss from Rhodes University, and there they have implemented a library
and packet generator for AVB, though they haven't yet published this code.

There also hasn't heppend any wide adoption of OSC, and may be OSC is
not that great? I am currently working on "Control and Monitoring
Protocol" which could take part in this architercture on it's TOP Layer.

The fallowing are the ABSTRACTION layers that i have thought being most general:

~>> Control, Monitoring and Information (CMI)
	ACMP (above mentioned above, it's kind of OSC-based)
	or AES-x170 (both can fit together)
	also OSC ..or even MIDI
	but ACMP is more general, it should be good for lighting and
	other controll applications ..

		here is the place for GUI interfaces,
				hardware controllers,
				control surfaces ...etc
		
~>> Signal Processing Subsystem (SPS)

	~>> Core Signal Bus (CSB) : our inter-connect
		it has one common clock
		one or more control ports
		and one or more signal ports
		(a port can be input, output, or both)

			the control ports are exposed to CMI layer

			the signal prorts can be:

					bridged (over Ethernet (i.e.  AVB), USB or FireWire)

					interfaced (to say I2S, AES/EBU, AES-50 ..MADI, ADAT)

					or streamed to a codec or
					uncompressed file dumping

				Let's call it an Port Exposure Layer

	~>> Core Signal Elements (CSE)
		the main abstraction for this is
		library (our cross-platform API)
	 	compiler (to produce platform dependent code)
		interpreter (to configure and glue the blocks)


~>> General Purpose Operating System
	Of course it is still there ..it could be on a remote machine
	or anything ..and it could be everywhere around,
	even General Purpose CPU could be a fall-back option
	..well, this is all about abstraction after all :)


This is with parallel audio clustering applications
and distributed chain processing in mind.

Looking forward to here some discussion,
I would like to set up a wiki and discusion list for this!

Regards,
-- 
Ilya Dmitrichenko 
Илья Дмитриченко 

email: errordeveloper@gmail.com
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: PROPOSAL: Layer Signal Processing Architecture

[Florian Faber]

On 07/29/10 22:20, Ilya D wrote:

> it's not to replace ALSA, but just to bring a different approach for
> design engineers of professional audio applications.
> we all know that these days a lot manufactuares chose Linux
> for their Mixing Consoles (such as Midas, Lawo, Calrec and others),
> also other products use Linux, but there might be only a few who use
> ALSA (as far as i could find out there rather NONE in pro-audio Linux devices).

What for would I use ALSA in a mixing console? In a mixing console I
control the user interface and a bunch of external DSP units.

Besides, audio interfaces become less important in pro audio with
upcoming transport over ethernet.

> ALSA had been designed for conventional sound-cards (largely) also there
> drivers for RME, DigiGram and other pro-interfaces,
> but the hardware is still proprietary and it isn't quite flexible.

What do you want to say with the latter? They are just interfaces, what
more should they do?

> Another motivating factor is upcomming completition of AVB ethernet
> standard from IETF/IEEE, there had been no publicaly avaliable code
> for this, nor i could find any discussions of how it could be
> implemented in Linux. However i have contact with a professor Richard
> Foss from Rhodes University, and there they have implemented a library
> and packet generator for AVB, though they haven't yet published this code.

You cannot do AVB in software.

> There also hasn't heppend any wide adoption of OSC, and may be OSC is
> not that great?

That depends on the job. For the purpose you stated - no it is not.


Flo
-- 
Machines can do the work, so people have time to think.
public key DA43FEF4          x-hkp://wwwkeys.eu.pgp.net

Re: PROPOSAL: Layer Signal Processing Architecture

[errordeveloper]

On Thu, Jul 29, 2010 at 10:52:01PM +0200, Florian Faber wrote:
> On 07/29/10 22:20, Ilya D wrote:
> 
> > it's not to replace ALSA, but just to bring a different approach for
> > design engineers of professional audio applications.
> > we all know that these days a lot manufactuares chose Linux
> > for their Mixing Consoles (such as Midas, Lawo, Calrec and others),
> > also other products use Linux, but there might be only a few who use
> > ALSA (as far as i could find out there rather NONE in pro-audio Linux devices).
> 
> What for would I use ALSA in a mixing console? In a mixing console I
> control the user interface and a bunch of external DSP units.

sure, ALSA doesn't fit in.

so the idea is to implement a cross-platform approach (even if the
number of platforms it would span about two or three DSPs)
> 
> Besides, audio interfaces become less important in pro audio with
> upcoming transport over ethernet.
sure, there we are talking about endpoints.

> 
> > ALSA had been designed for conventional sound-cards (largely) also there
> > drivers for RME, DigiGram and other pro-interfaces,
> > but the hardware is still proprietary and it isn't quite flexible.
> 
> What do you want to say with the latter? They are just interfaces, what
> more should they do?
> 
yep, sure. but i was talking about a card that would have configurable
processing block, and the implementation of each block could be updated
by the user.

> > Another motivating factor is upcomming completition of AVB ethernet
> > standard from IETF/IEEE, there had been no publicaly avaliable code
> > for this, nor i could find any discussions of how it could be
> > implemented in Linux. However i have contact with a professor Richard
> > Foss from Rhodes University, and there they have implemented a library
> > and packet generator for AVB, though they haven't yet published this code.
> 
> You cannot do AVB in software.
well, i'm sure you can fake it, it won't be the best,
but with some optimization you could surely implement it so
that it would allow at least one channel each way!

> 
> > There also hasn't heppend any wide adoption of OSC, and may be OSC is
> > not that great?
> 
> That depends on the job. For the purpose you stated - no it is not.
well ..i didn't quite mention what the principle of ACMP are,
it's still work in progress at very early stage, because i don't have
the time to write everything down propertly right now.
> 
> 
> Flo
> -- 
> Machines can do the work, so people have time to think.
> public key DA43FEF4          x-hkp://wwwkeys.eu.pgp.net
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: PROPOSAL: Layered Signal Processing Architecture (was: "Layer Signal Processing Architecture")

[errordeveloper]

sorry for the typo in the subject