Joern Nettingsmeier's hands, ill-advised and unbeknownst to his higher brain functions, typed thusly: sorry, i just double-checked: no quotes, everything after the first "=" up to the newline winds up in the data. woops, you don't kill -HUP, but kill -USR1. sorry. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan Jörn Nettingsmeier Lortzingstr. 11, 45128 Essen, Germany http://spunk.dnsalias.org (my server) http://www.linuxaudiodev.org (Linux Audio Developers)

hi eric! Eric Dantan Rzewnicki wrote: yes. there is a jack graph that is producing sounds. ices-jack is just another jack client. it does the encoding to ogg and optional resampling and then sends the encoded stream to an icecast server (which can be on another machine or local, the transmission between source and server is via http) yes, i did that during testing of the lac streaming setup this year. works nicely. in the ices process. so if you use two boxen, the big iron should be the jackd/ices box, since the encoding is computationally expensive. the streaming can be done by a leftover - i guess a pentium 233 running icecast can saturate a 100mbit link. you want some memory though. the icecast box does not need the *-tools. (nor does ices strictly speaking, but they are nice to have). i described a "bleeding edge" best-of-xiph.org setup. if you don't want to play with video or very-low-bandwidth speech streaming, you can omit the speex and theora packages as well as flac. ices/icecast check for them at compile time - i wanted all bells and whistles, but if the libs are not present, those features will be left out with no problems. you may even get away with using your distro's libvorbis, although i think ices-kh does require ogg2 and won't compile with plain old ogg. yes, sorry for my sloppy choice of words. when you do this, consider that under ideal circumstances, re-ogging a pcm stream that has been ogg-encoded before will not add new encoding artifacts, unless you reduce the bitrate. the degradation you hear on my recording is mostly due to repeated ad/da conversion, a mixer that catches harddisk hum and a reduction of the level.... maybe ogg->wav->mp3->wav and back would be more interesting. both codecs should have different data reduction models and ideally not only take away information but create artifacts different from each other. or maybe add an analog edge to your graph (pun intended :-). you need one ices process per such instance. ices can encode to different bitrates, but handles only *one* incoming stream (which can have an arbitrary number of channels). hmm. the internet tranmission does not generate any interesting additions, except for possibly varying round-trip times or maybe dropouts.... i don't understand this, but yes, ices can be made to start a new dump file at any time by sending it a USR1 signal. make it a cronjob and there you go. :) good luck! -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan Jörn Nettingsmeier Lortzingstr. 11, 45128 Essen, Germany http://spunk.dnsalias.org (my server) http://www.linuxaudiodev.org (Linux Audio Developers)

Karl Heyes wrote: in that case, there seems to be a minor oddity with the ices configuration script - a friend tried to build it on a debian testing box, and he got errors that looked like a missing libogg2 - maybe i misinterpreted the message. anyway, i assumed it was needed and built it. but you are of course right, neither my ices nor the icecast binary actually link to libogg2... sorry for the misinformation. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan Jörn Nettingsmeier Lortzingstr. 11, 45128 Essen, Germany http://spunk.dnsalias.org (my server) http://www.linuxaudiodev.org (Linux Audio Developers)

On Wed, Sep 22, 2004 at 12:50:52AM +0100, Karl Heyes wrote: Thanks Karl. My composition-thing will decode previously encoded portions of the stream, apply manipulations (time-stretch/compress & possible reversing) and then mix them together with others similarly manipulated. Additionally, the recording portion of the system will choose a vorbis quality at random from the range of worst-best for each recording. So, there will be some effect from the encode-decode cycles. But, even if that effect is minimal the system still messes with time scale stretch/compress, reversal of audio data and mixing streams together at random. Something interesting, at least to me, will come of it. The ogg vorbis part at least provides a larger pool of previous recordings to feed back into the system by virtue of saving some disk space. -Eric Rz.