Subject: Proposition: Ecasound Blocking Audio Interface
From: janne halttunen (jhalttun_AT_pp.htv.fi)
Date: Sun Mar 02 2003 - 19:10:38 EET
Ecasound Blocking Audio Interface (EBAI)
I have for long have had the need some how to route audio to ecasound from my own little programs.
First approaches have been something like:
$ myprogram | ecasound -i stdin
but to use ecasound's wonderful multitracking capabilities, a more complex approach must be assumed. Yet it's simple: FIFOs.
$ mkfifo track1.raw
$ mkfifo track2.raw
And when I have my program writing to those FIFOs, I can start ecasound on them:
$ ecasound -a 1 -i track1.raw -a 2 -i track2.raw
This works, but it is a pain to write the same things always all over again. Hence, I propose standardization.
Keeping it simple.
-open_port( name )
Create EBAI port.
In practice this means creating a FIFO to standard place, say:
"/tmp/eai-(ecasound-pid)/(port-name).raw", and then registering the port name alias to some place in Ecasound Control Interface.
So that through ECI you could do: "ai-add (port-name)", which would resolve to the full: "/tmp/eai-(ecasound-pid)/(port-name).raw".
It is up to the API user to keep track of which ports are for writing and which for reading.
-write_port( name, data )
Write data to the named port.
-read_port( name )
Read data from named port.
-flush_port( name )
Flush buffered data from named port.
And that's it. Do we need more?
I'm pretty much set up to write the python implementation of this, integrating it with the native implementation of ECI, but I thought it would be best to ask for comments first before doing it.
So comments are welcome,
This archive was generated by hypermail 2b28 : Sun Mar 02 2003 - 19:04:54 EET