WebPd isn't able to deal with really heavy patches. In fact that performance was running the biggest patch I've ever tried with it, you can judge by yourself whether that's heavy :
https://gist.github.com/sebpiq/5462949
I would say the biggest problem with WebPd right now is its lack of objects. You have to be very minimalistic when composing :)
The only latency there is the messages that you server sends to the client running WebPd. I couldn't tell you how much that is.
2013/4/25 onyx@onyx-ashanti.com onyxashanti@gmail.com
cool video.
I dont know if my synthesis and performance system would work from a server and if it did, i doubt i would get the 2-5ms latency i am comfortably getting now. is webpd able to deal with heavy patches? the idea sounds interesting. what is the realtime latency of webpd in real terms?it might be cool, if the latency is controllable and if it can scale with evolving complexity. thanks!
On Thu, Apr 25, 2013 at 10:03 PM, s p sebpiq@gmail.com wrote:
Or you could try a different approach. Instead of streaming the audio, generate it client-side ... example, this performance that I did last week-end with WebPd : https://vimeo.com/64514693
2013/4/25 august august@alien.mur.at
Onyx,
Interesting idea.
What kind of threshold are you looking for regarding latency? I assume this would be for a local network, right?
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
...
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.
best -august.
onyx@onyx-ashanti.com say:
Greetings! I hope all is well with you. I wanted to ask if i might
gain
some of your insight on a project i am undertaking.
I am currently attempting to stream my audio into html5 capable web browsers of smartphones. i have created a local network and installed nginx as my webserver. i and a friend got everything working with the oggcast~ and mp3cast~ objects and the icecast 2 server, but the
latency was
horrific-5-15seconds. I would like to investigate the idea of taking advantage of the plugin-less nature of these modern fast browsers and
pipe
the audio directly into it as directly as possible the same way voip
works
but lower bandwidth and only one way.
I see that udpsend~ can do alot of what i think i want, but i am
confused
as to how i might connect it with the audio socket in the client
browser
(if socket is even the right term).
Any insight would be greatly appreciated. and if i get it working, as before, i will document the findings in a step by step once it works. thank y> cheers!
Onyx
-- www.onyx-ashanti.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
-- http://aug.ment.org GPG: 0A8D 2BC7 243D 57D0 469D 9736 C557 458F 003E 6952
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- www.onyx-ashanti.com