Hi Richard, if the two machines are on the same LAN, have a look at netjack: http://netjack.sourceforge.net/
you are casting from one patch to an icecast server (running on the same machine) and then receiving it from another? Perhaps direct peer2peer streaming could reduce the latency? Yves has one mp3live~ object, as far as i recall: http://ydegoyon.free.fr/software.html I remember a talk on LAC2006 about LDAS: http://lac.zkm.de/2006/proceedings.shtml#saebo_svensson hope that helps a bit. lgPP Richard Lewis wrote: > Hello PD-list, > > I'm still working on my mp3cast~ project :-) > > The final problem (I hope) is that I experience quite considerable latency on > the client-side of around 10-12 seconds. The application is supposed to be > real-time so this latency is quite a problem. > > A colleague suggested that it could be Icecast using a fixed size buffer. I > had a look through the Icecast source code but couldn't find anything > hopeful. So I put a message on the Icecast forum and was told to try reducing > the burst-on-connect size to 0. I did this and it didn't seem make any > difference. > > Of course, buffering could be the problem, but there are four places where > buffering could occur: 1) in the client media streamer; 2) in the streaming > server output; 3) in the streaming server source/input; and 4) in the source > encoding (in this case, mp3cast~). > > I've made some attempts at checking cases 2 and 3. 4 is problematic in that I > can't control what a user's client does. (I can provide documentation, > though). > > So I'm trying to check case 4. Google returns four or five hits for "mp3cast~ > buffering", one of which is one my previous posts to this list! > > Does anyone know how mp3cast~ buffering is controlled and if it is > configurable either by a setting or source code hack? > > Cheers, > Richard _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
