[zeromq-dev] use zeromq for pgm audio broadcast to android devices ?

[Dan Reardon]

We were drawn because of the notion that zeromq contained a version of openpgm which ran on android.
Are you saying it runs on android but does not support wifi ? We would be talking about the udp encapsulated
pgm of course. In my experiments with trying a vanilla java.net multicast the low transfer rate was a major 
problem, and I was hopping for something better, with a lower level program which in addition to doing FEC
and NAK could set a higher transfer rate. Am I barking up the wrong tree ?

> From: ph at imatix.com
> Date: Wed, 2 Jan 2013 20:40:54 +0100
> To: zeromq-dev at lists.zeromq.org
> Subject: Re: [zeromq-dev] use zeromq for pgm audio broadcast to android devices ?
> 
> I'm pretty sure (but Stephen can confirm) that WiFi switches do not
> offer IGMP snooping, which PGM requires.
> 
> Over WiFi your choices are either TCP, for up to 8-10 devices, or UDP
> multicast (probably with recovery over TCP) thereafter. I've not seen
> an open source UDP+0MQ mass transfer protocol; it would be
> interesting.
> 
> You need to beware with any multicast over UDP since the bitrate the
> switch will use will be extremely low, even if all devices are close
> by.
> 
> The quality of work you can do over WiFi depends seriously on the WiFi
> switch quality, interference, and physical spread of the network.
> 
> -Pieter
> 
> On Wed, Jan 2, 2013 at 7:27 PM, Dan Reardon <dtr29 at hotmail.com> wrote:
> > We are new to ZeroMQ and want to use it to distribute media over wifi to
> > phones and other devices, potentially a very large number.
> >
> >
> > (a) Has anyone used PGM over WIFI to devices yet? Anyone tried it with
> > hundreds or thousands of phones? (b) How well does it (or should it) work?
> > (c) If the wifi / electrical environment is dirty, will zeroMQ's queuing
> > mechanisms get in my way? (e) What other issues should I expect to have to
> > work around? (f) Tricks and tips?
> >
> >
> > We do not need or want
> >
> > "guaranteed delivery", as this is a real time broadcast, missing
> >
> > audio segments should be substituted with silence when the cannot
> >
> > be obtained in time to keep up with the audio stream. Will we run into
> > problems BECAUSE of message queuing we don’t want or is there a way to get
> > in under that layer and avoid queues overflowing, etc.?
> >
> >
> > Is there any chance that anyone would want to implement Uflood, Ucast or any
> > other protocol specifically designed for wifi? How do we get this onto the
> > “wish list” or product road map?
> >
> >
> > We may be in a position to provide a testbed environment for large-scale
> > wifi testing if someone else wants to develop the code! Who should we be
> > talking to? Anyone interested in being the lead archtect or developer if we
> > can support testing?
> >
> >
> >
> >
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130103/8e724e60/attachment.htm>