On Thu, Apr 25, 2013 at 10:54 PM, august <august@alien.mur.at> wrote:

> > What kind of threshold are you looking for regarding latency?
>
> No more than 100ms. I feel that should be achievable with a close range
> private network.

hmm.  I'm not so sure you'll be able to get 100ms or less.  Each
component in your set up is going to need some buffering.  With
an ideal streaming setup, you have at least 2 components: the streamer
and the receiver, each with buffering.

With your setup, you have even more: pd+oggcast, icecast, audio player.

Depending on your network, you could have extra buffering for wireless ,
packet filtering etc.

You might be able to whittle it down even further by dumping oggcast~
and then using low-latency pd+jack.  Then just stream directly from jack.
There may even be a wav streamer.  If not it would be simple to write.

I am open to this option. I dont see a reason why i shouldnt be able to take the audio from something like [netsend~] and dump it to a port, then push that out to (???) so it comes out of the browser or media player of the device in realtime.  I am very not married to oggcast or icecast or any cast.  my only real hinderance is my lack of knowledge of the protocols.  although i will say that websockets look really really good.  i'm investigating some way of creating a sort of one-way voip thing.  that definitely comes in around 50-100ms and most voip sounds pretty good even over the internet so a local feed should be very decent.  the jack idea looks interesting.  how would that work?

Onyx

> > I assume this would be for a local network, right?
>
> Yes
>
> > If I were you, I would first try to fine-tune your current setup by
> > getting all latency variables as low as possible (icecast, pd+oggcast~,
> > and the html audio player).
> >
> > ICECAST:  There should be config settings for it where you can manage
> > the buffering/latency.  Usually buffering/latency is good for streaming
> > media since you never know what will happen on the network.
> >
> > oggcast~ : I'm guessing it is as low as it can go right now, but there
> > may be an internal buffer that you can adjust/downsize.
> >
> > HTML audio player: Most importantly, in the HTML, you should check to
> > make sure that the audio is not buffering. My guess is that this is
> > where you are experiencing the largest latency.  Since HTML5 is a
> > moving target, I'm not sure how you would currently do that.  May not
> > even be possible.
> > https://developer.mozilla.org/en-US/docs/HTML/Element/audio
>
> Thanks! I will check all of those tonight. Websockets for HTML 5 looks like
> it might be the ticket. They seem to be catering to the gamers, so I think
> that might work as well as allow future development.
> >
> > ...
> >
> >
> > Then, if the above didn't work, you might try to hook up the output of
> > a TCP netsend to a websocket and then translate the audio data chunks
> > into JS Audio.  UDP won't work on websockets AFAIK.
>
> I will try this tonight! Netsend formats the audio in a manner that the
> Websockets understand? If that is the case, then it is Christmas!

Unfortunately, it will be more like a devout catholic easter.  You;ll
have to fast for 40 days to get some candy!

Websockets are pretty new and the implementation in browsers is shoddy.
You would have to script it all yourself and then write the output in
the browser using the html5 audio api....which is another can of worms.


suerte!

-a.

--

www.onyx-ashanti.com