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