Subject: Re: [ecasound] output speed and stdout
From: Jeremy Hall (jhall@uu.net )
Date: Mon Sep 06 1999 - 23:28:46 EEST
well, that sacrefices /dev/dsp for this use.
I have several computers in various parts of the house, connected to
ethernet. Originally, this scheme was designed to allow multiple mp3
encoders to see the same audio stream so they could encode at different
rates. If you're not familiar with ip multicast, it is a many-to-many
application, where many users can send to a "group". All subscribers to
the group receive the data. An efficient forwarding tree is built in the
network so that data replication occurs as closely to the receiver as
possible.
There is usually one main group, 239.1.1.1, that is active in the house.
Any computer subscribed to 239.1.1.1/24430 (the port is 24430) will
receive this data and play it. There is a small delay as the signal
routes through the house in ethernet, but that is on the order of 2 or 3
miliseconds, hardly noticable.
Each process can do what it likes with the data it receves--most just play
it, but some perform filtering actions and then send that data on a
different group, for example, an mp3 encoder. In the lame case, lame
pulls the live stream and makes raw mp3 out of it, sending that data to a
new group. Another process reads the raw mp3 data and encapsulates this
into RTP for announcement on the internet. (RTP is a standard protocol
understood by many)
Users can pull this RTP stream directly from here, and it will fan out in
the network properly. You may be multicast capable--ask your system
administrator if interested.
So all this can go on, each computer doing its own thing, one can sample,
one can encode, and one can run Ecasound. The one running ecasound need
not even have a sound card in it, since it can pull data off the wire, do
its thing, and shove it back on another group. For now I have it pulling
off the live feed, effect processing, then sending to another group where
the machine in front of me is listening to. Once I figure out how to
change chains and effects midstream, it can remain active all the time if
somebody wants it, and 239.1.1.3/24430 is the "ecasound" group.
so when the recording studio is in place, ecasound could act as an effects
rack or multitrack processor. If one could send each track to a separate
group, that would be ideal, because an ecasound at the other end could
just put back together all the tracks you need and then you have a 2-track
master.
problems associated with this plan:
1: how do you fastforward or rewind individual tracks?
2: how do you change panning or volume real-time on a running ecasound?
3: how do you patch in effects inline as the stream is recording?
4: could a scripting language be developed so that each track could be
"adjusted" automatically for a final product
5: how does one synchronize all the tracks together?
so those are a few of my ideas. What do you think of them?
_J
Kai Vehmanen said:
> On Mon, 6 Sep 1999, Jeremy Hall wrote:
>
> > I got it to compile, but I am now looking for some type of loopback device
> > in OSS, or the ability to write with correct timing. I have multiple
> [...]
> > working. I can feed a named fifo off to the transmission program, but if
> > ecasound sends at faster than real-time, I get overruns on the receiver,
> > and I spike the bw used on my ethernet hub. Do you have suggestions?
>
> I'd like to know more about your setup and ecasound's role
> in all this? Anyway, you can synchronize std-output to realtime
> by using an extra OSS-output target... So something like..:
>
> ecasound -a:1,2 -i input_file.wav \
> -a:1 -o stdout \
> -a:2 -o /dev/dsp
>
> ... will write data to stdout at real-time speed.
>
> --
> Kai Vehmanen ----------------------------- CS, University of Turku, Finland
> : email mailto:kaiv@wakkanet.fi
> : audio processing for linux http://www.wakkanet.fi/ecasound/
> : my music (ambient-idm-rock-...mp3/ra) http://www.wakkanet.fi/sculpscape/
>
>
>
>
>
This archive was generated by hypermail 2a24 : Sat Sep 25 1999 - 19:41:06 EEST