Subject: Re: [ecasound] more audio stamp examples
From: Jeremy Hall (jhall@uu.net)
Date: Thu Dec 14 2000 - 07:53:59 EET
ok I still don't quite get it.
At UUNET, we have several classifications of routes, those we hear from
peers, those we hear from customers, those from internal ases, etc. To
distinguish these, we apply something called a BGP community, for example:
If a customer sends us a route and applies the community 701:120, our
border router with him will set a parameter called local preference to
120, a parameter not normally setable by an external entity. This
transitive attribute (the community) can later be used by other routers in
the network to perform special actions on this particular prefix. In a
way, we are colouring routes and potentially could colour traffic.
now the eS option seems to mark and copy "special" traffic, that which is
the result of efl, this traffic is stored in a global buffer available for
any chain or interface...thus it seems possible to merge two chains, the
loop object could be modified to use this technology rather than its own
processing
The ksv I do not understand. Build me a network with it and I'll probably
get it.
I guess I'm getting old.
_J
In the new year, Kai Vehmanen wrote:
> On Wed, 13 Dec 2000, Jeremy Hall wrote:
>
> > Is this thing like a tag applied to some special data, allowing it to be
> > friends with another chain?
>
> You can think of audio stamps as locations for storing one buffer of audio
> data (-b:x -> one buffer contains x sample frames). Every '-eS:x' creates
> a new audio stamp location, identified by the 'stamp-id', which is
> interpreted as an integer number. In addition, audio stamps are not
> specific to chains, but are a chainsetup-wide concept. In other words, a
> audio stamp stored in chain "1" is usable by all operators present in the
> same chainsetup.
>
> > or maybe a colour? you colour some of the input data and then can use it
> > for input to a controller?
>
> Ok, I see what you mean. Audio stamps are not coloured or marked
> (like what routers do for ip-packets' tos-fields), but audio is
> actually duplicated and copied to a new location while it's passing the
> '-eS:x' operator.
>
> Similarly, audio stamp clients (or consumers) get a pointer to a buffer
> of samples with a certain 'stamp-id'.
>
> One problem we still have is the order of processing events. At the
> moment, chains are processed in a certain order. But this isn't something
> you necessarily should rely on. It might be, that some ecasound version
> introduces a mix engine that processes chains in parallel. This causes
> problems for all uses of audio stamps, for which order of events is
> important. Even now we have one problem caused by event ordering. Inside
> one chain, all controller values are updated before any chain operators
> are processed. So when you issue:
>
> ecasound -a:1 -i drum_loop.wav -o /dev/dsp -eS:1 -efl:400 -ksv:1,20,20000,1,1
>
> ...the first loop goes like this:
>
> 1. read a buffer of 'drum_loop.wav'
> 2. copy the audio to chain "1"
> 3. update all controller values (nothing written to stamp '1' yet,
> so -ksv will produce control value of 0 which is mapped to 20Hz)
> 4. process chainops
> 4.1 -eS:1 stores the audio buffer to stamp-buffer '1'
> 4.2 lowpass filter is applied to signal with cutoff-freq 20Hz
> 5. mix from chain buffer to output ("1" -> /dev/dsp
>
> ... so there's a one buffer delay in stamp processing. Now one solution -
> although not trivial to implement - would be put both both controllers and
> chainops in the same ordered list, but this seems as a difficult thing to
> implement without slowing down all other use cases.
>
> --
> . http://www.eca.cx ... [ audio software for linux ] /\ .
> . http://www.eca.cx/sculpscape [ my armchair-tunes mp3/ra/wav ]
>
>
> --
> To unsubscribe send message 'unsubscribe' in the body of the
> message to <ecasound-list-request@wakkanet.fi>.
>
-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Thu Dec 14 2000 - 07:58:33 EET