<div dir="ltr"><div><div><div><div><div>I was just wondering. would it be possible to use the mp3streamout~ object to stream directly to a modern browser? to make it listen for the stream somehow, without shout/icecast, and just play?<br>
<br></div>shouldnt it be as simple as;<br><br></div>pd to mp3streamout<br></div>mp3streamout to port number<br></div>port to (i dont know...websocket, voodoo, tardis...) to browser, just blasting.<br><br></div>or, possibly to create, say, 50 mp3streamouts, each with their own port, which could be served up by the webserver?basically, pd would be the server. of course i dont know what i am talking about but can any of these work<br>
<div><br><div><div><div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 25, 2013 at 11:21 PM, <a href="mailto:onyx@onyx-ashanti.com">onyx@onyx-ashanti.com</a> <span dir="ltr"><<a href="mailto:onyxashanti@gmail.com" target="_blank">onyxashanti@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">On Thu, Apr 25, 2013 at 10:54 PM, august <span dir="ltr"><<a href="mailto:august@alien.mur.at" target="_blank">august@alien.mur.at</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>> > What kind of threshold are you looking for regarding latency?<br>
><br>
> No more than 100ms. I feel that should be achievable with a close range<br>
> private network.<br>
<br>
<br>
</div>hmm. I'm not so sure you'll be able to get 100ms or less. Each<br>
component in your set up is going to need some buffering. With<br>
an ideal streaming setup, you have at least 2 components: the streamer<br>
and the receiver, each with buffering.<br>
<br>
With your setup, you have even more: pd+oggcast, icecast, audio player.<br>
<br>
Depending on your network, you could have extra buffering for wireless ,<br>
packet filtering etc.<br>
<br>
You might be able to whittle it down even further by dumping oggcast~<br>
and then using low-latency pd+jack. Then just stream directly from jack.<br>
There may even be a wav streamer. If not it would be simple to write.<br></blockquote><div><br></div></div><div>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?<br>
<br></div><div>Onyx<br></div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div><br>
<br>
<br>
> > I assume this would be for a local network, right?<br>
><br>
> Yes<br>
><br>
> > If I were you, I would first try to fine-tune your current setup by<br>
> > getting all latency variables as low as possible (icecast, pd+oggcast~,<br>
> > and the html audio player).<br>
> ><br>
> > ICECAST: There should be config settings for it where you can manage<br>
> > the buffering/latency. Usually buffering/latency is good for streaming<br>
> > media since you never know what will happen on the network.<br>
> ><br>
> > oggcast~ : I'm guessing it is as low as it can go right now, but there<br>
> > may be an internal buffer that you can adjust/downsize.<br>
> ><br>
> > HTML audio player: Most importantly, in the HTML, you should check to<br>
> > make sure that the audio is not buffering. My guess is that this is<br>
> > where you are experiencing the largest latency. Since HTML5 is a<br>
> > moving target, I'm not sure how you would currently do that. May not<br>
> > even be possible.<br>
> > <a href="https://developer.mozilla.org/en-US/docs/HTML/Element/audio" target="_blank">https://developer.mozilla.org/en-US/docs/HTML/Element/audio</a><br>
><br>
> Thanks! I will check all of those tonight. Websockets for HTML 5 looks like<br>
> it might be the ticket. They seem to be catering to the gamers, so I think<br>
> that might work as well as allow future development.<br>
> ><br>
> > ...<br>
> ><br>
> ><br>
> > Then, if the above didn't work, you might try to hook up the output of<br>
> > a TCP netsend to a websocket and then translate the audio data chunks<br>
> > into JS Audio. UDP won't work on websockets AFAIK.<br>
><br>
> I will try this tonight! Netsend formats the audio in a manner that the<br>
> Websockets understand? If that is the case, then it is Christmas!<br>
<br>
</div></div>Unfortunately, it will be more like a devout catholic easter. You;ll<br>
have to fast for 40 days to get some candy!<br>
<br>
Websockets are pretty new and the implementation in browsers is shoddy.<br>
You would have to script it all yourself and then write the output in<br>
the browser using the html5 audio api....which is another can of worms.<br>
<br>
<br>
suerte!<br>
<span><font color="#888888"><br>
-a.<br>
<br>
</font></span></blockquote></div></div></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br><div><div><a href="http://www.onyx-ashanti.com" target="_blank">www.onyx-ashanti.com</a></div><br></div>
<a title="phone number" style="color:rgb(0,0,63);background-color:rgb(255,255,191)"><br>
</a>
</font></span></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div><div><a href="http://www.onyx-ashanti.com" target="_blank">www.onyx-ashanti.com</a></div><br></div><a title="phone number" style="color:rgb(0,0,63);background-color:rgb(255,255,191)"><br>
</a>
</div></div></div></div></div></div></div></div>