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 you.
cheers!
Onyx
Well, [udpsend~] is meant to work with [udpreceive~], so you really have to run Pd on both ends of the connection. Of course you are free to modify the code to make it work with your setup -- that would mean integrating [udpsend~] into the server and [udpreceive~] into the clients' browsers, which I have no idea how to do.
Martin
On 2013-04-25 10:14, onyx@onyx-ashanti.com wrote:
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 you.
cheers!
Onyx
-- www.onyx-ashanti.com http://www.onyx-ashanti.com
Thanks for getting back to me do quickly.
Is there a network audio object (s) that can output standard formatted audio? On Apr 25, 2013 4:32 PM, "Martin Peach" martin.peach@sympatico.ca wrote:
Well, [udpsend~] is meant to work with [udpreceive~], so you really have to run Pd on both ends of the connection. Of course you are free to modify the code to make it work with your setup -- that would mean integrating [udpsend~] into the server and [udpreceive~] into the clients' browsers, which I have no idea how to do.
Martin
On 2013-04-25 10:14, onyx@onyx-ashanti.com wrote:
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 you.
cheers!
Onyx
-- www.onyx-ashanti.com http://www.onyx-ashanti.com
On 2013-04-25 10:36, onyx@onyx-ashanti.com wrote:
Thanks for getting back to me do quickly.
Is there a network audio object (s) that can output standard formatted audio?
I don't know. netjack? The thing with browsers is they run TCP, which is not good for low-latency audio. Maybe you want a separate UDP audio link, but I don't know how to integrate that with a browser.
Martin
On 04/25/2013 04:36 PM, onyx@onyx-ashanti.com wrote:
Thanks for getting back to me do quickly.
Is there a network audio object (s) that can output standard formatted audio?
i've started writing an RTP infrastructure for Pd [1], though it currently only supports uncompressed audio. RTP is a pretty standard protocol, and latency can go down to a few ms. there are also RTCP components. keep in mind though, that this is not a "plug-and-play" object, but instead a framework (so you might need to know what RTP is and ow it works in order to get it do what you want).
whether it works in browser or not, i don't know. keep in mind, that browsers are still mainly consumer goods, and as such latency doesn't matter so much (if you only listen to a stream on a remote place it doesn't matter if it is 10ms behind or 2mins - since there is no feedback and nothing to compare with, tere is no "absolute" time)
gfamdr IOhannes
IOhannes zmölnig wrote:
i've started writing an RTP infrastructure for Pd [1], though it currently only supports uncompressed audio. RTP is a pretty standard protocol, and latency can go down to a few ms. there are also RTCP components.
May I add that firewalls have a tendency to kill RTP/RTCP, too. Don't expect it to work everywhere. Just like active FTP some years ago.
Cheers, Charles
----- Original Message -----
From: IOhannes zmölnig zmoelnig@iem.at To: pd-list@iem.at Cc: Sent: Friday, April 26, 2013 5:21 AM Subject: Re: [PD] direct connection from pd to webrowser, low latency
On 04/25/2013 04:36 PM, onyx@onyx-ashanti.com wrote:
Thanks for getting back to me do quickly.
Is there a network audio object (s) that can output standard formatted audio?
i've started writing an RTP infrastructure for Pd [1], though it currently only supports uncompressed audio. RTP is a pretty standard protocol, and latency can go down to a few ms. there are also RTCP components. keep in mind though, that this is not a "plug-and-play" object, but instead a framework (so you might need to know what RTP is and ow it works in order to get it do what you want).
whether it works in browser or not, i don't know. keep in mind, that browsers are still mainly consumer goods, and as such latency doesn't matter so much (if you only listen to a stream on a remote place it doesn't matter if it is 10ms behind or 2mins - since there is no feedback and nothing to compare with, tere is no "absolute" time)
www.webrtc.org/
There's already a working demo for audio/video conferencing with firefox nightly (and maybe chrome).
One of the claimed benefits is the ability to connect and send data peer-to-peer with nat traversal, although the claim is made in such a cavalier manner about such a disruptive feature that I'm suspicious there are a thousand catches.
-Jonathan
gfamdr IOhannes
[1] https://github.com/iem-projects/pd-iemrtp
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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
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
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
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
Hi Onyx,
What is your aim, do you want to entertain your (physically present) audience via smart phones instead of PA system?
I have a similar quest pending: to send Pd audio from a wearable computer over wireless to PA system. It's simpler than your purpose (because it does not involve an internet browser), but still complicated enough. So far I've learned that UDP is the preferred protocol for real time audio transmission, because it can go one way without the time-consuming error-checking and recovery.
Smart phones only do wireless, and wireless suffers a lot from packet loss, and packet loss must be concealed with clever dsp routines. Besides that, there is the (in this case relatively minor) issue of clock drift between two sound card clocks. Even if you send audio between two computers with [udpsend~] / [udpreceive~] over an ad hoc (point to point) wireless network you'll notice these issues. Just try it with two laptops and you'll see what I mean to say (here's how to set up ad hoc wireless network: https://help.ubuntu.com/community/WifiDocs/Adhoc).
Still I think that ad hoc networking would be the way to go for low latency local wireless connection. It would not work with regular internet browsers though. A yet to design (Pd or Jack based) app would be required at the receiving end, which does packet concealment and clock drift compensation.
About clock drift compensation, Miller Puckette had a hint a while ago, very probably referring to this article:
http://kokkinizita.linuxaudio.org/papers/adapt-resamp.pdf
Katja
On Thu, Apr 25, 2013 at 4:14 PM, onyx@onyx-ashanti.com < onyxashanti@gmail.com> wrote:
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 you.
cheers!
Onyx
-- www.onyx-ashanti.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
From: katja katjavetter@gmail.com To: "onyx@onyx-ashanti.com" onyxashanti@gmail.com Cc: pd-list Pd-list@iem.at; Martin Peach martin.peach@sympatico.ca Sent: Friday, April 26, 2013 4:08 PM Subject: Re: [PD] direct connection from pd to webrowser, low latency
Hi Onyx,
What is your aim, do you want to entertain your (physically present) audience via smart phones instead of PA system?
I have a similar quest pending: to send Pd audio from a wearable computer over wireless to PA system.
Why not send FUDI to a box connected directly to the PA system?
-Jonathan
That's a fairly brilliant idea. No need for fancy audio-quality wireless units, either.
Phil
On 4/26/13 1:19 PM, Jonathan Wilkes wrote:
From: katja katjavetter@gmail.com To: "onyx@onyx-ashanti.com" onyxashanti@gmail.com Cc: pd-list Pd-list@iem.at; Martin Peach martin.peach@sympatico.ca Sent: Friday, April 26, 2013 4:08 PM Subject: Re: [PD] direct connection from pd to webrowser, low latency
Hi Onyx,
What is your aim, do you want to entertain your (physically present) audience via smart phones instead of PA system?
I have a similar quest pending: to send Pd audio from a wearable computer over wireless to PA system.
Why not send FUDI to a box connected directly to the PA system?
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Yeah, sending FUDI would be good. Or OSC. In case of synthesis, better send controller data instead of audio.
In my case (sending processed acoustic audio input) that wouldn't work, but never mind.
Katja
On Fri, Apr 26, 2013 at 10:36 PM, Phil Stone pkstone@ucdavis.edu wrote:
That's a fairly brilliant idea. No need for fancy audio-quality wireless units, either.
Phil
On 4/26/13 1:19 PM, Jonathan Wilkes wrote:
______________________________**__
From: katja katjavetter@gmail.com To: "onyx@onyx-ashanti.com" onyxashanti@gmail.com Cc: pd-list Pd-list@iem.at; Martin Peach martin.peach@sympatico.ca Sent: Friday, April 26, 2013 4:08 PM Subject: Re: [PD] direct connection from pd to webrowser, low latency
Hi Onyx,
What is your aim, do you want to entertain your (physically present) audience via smart phones instead of PA system?
I have a similar quest pending: to send Pd audio from a wearable computer over wireless to PA system.
Why not send FUDI to a box connected directly to the PA system?
-Jonathan
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
From: katja katjavetter@gmail.com To: Phil Stone pkstone@ucdavis.edu Cc: Jonathan Wilkes jancsika@yahoo.com; pd-list Pd-list@iem.at Sent: Friday, April 26, 2013 5:11 PM Subject: Re: [PD] direct connection from pd to webrowser, low latency
Yeah, sending FUDI would be good. Or OSC. In case of synthesis, better send controller data instead of audio.
In my case (sending processed acoustic audio input) that wouldn't work, but never mind.
Btw-- are you sending compressed or uncompressed audio?
Katja
On Fri, Apr 26, 2013 at 10:36 PM, Phil Stone pkstone@ucdavis.edu wrote:
That's a fairly brilliant idea. No need for fancy audio-quality wireless units, either.
Phil
On 4/26/13 1:19 PM, Jonathan Wilkes wrote:
From: katja katjavetter@gmail.com To: "onyx@onyx-ashanti.com" onyxashanti@gmail.com Cc: pd-list Pd-list@iem.at; Martin Peach martin.peach@sympatico.ca Sent: Friday, April 26, 2013 4:08 PM Subject: Re: [PD] direct connection from pd to webrowser, low latency
Hi Onyx,
What is your aim, do you want to entertain your (physically present) audience via smart phones instead of PA system?
I have a similar quest pending: to send Pd audio from a wearable computer over wireless to PA system.
Why not send FUDI to a box connected directly to the PA system?
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sat, Apr 27, 2013 at 1:31 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
Btw-- are you sending compressed or uncompressed audio?
Uncompressed, 16 bit ints. Compression requires analysis, introducing extra latency. I'm not using it in practice yet, as I still have to find (or develop) a solution for packet loss concealment.
As of now, I use a cheap work-around for wireless monitoring only: an FM 'stereo' transmitter and receiver. FM stereo does not send over two frequency channels, therefore audio quality is suboptimal, not suitable for regular PA situations. However it may be suitable for 'silent concert' experiments in small venues.
Onyx, is that an idea? Most cell phones do have an FM receiver. They only work with wired headset connected, functioning as antenna. As wired headsets can be cheap, just offer them for sale during the event. The good thing with FM is, it has zero latency. I got a LinexFM transmitter from here:
Rumors go that USA versions have higher transmission power than the ones sold in Europe.
Katja
From: katja katjavetter@gmail.com To: Jonathan Wilkes jancsika@yahoo.com Cc: Phil Stone pkstone@ucdavis.edu; pd-list Pd-list@iem.at Sent: Saturday, April 27, 2013 5:24 AM Subject: Re: [PD] direct connection from pd to webrowser, low latency
On Sat, Apr 27, 2013 at 1:31 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
Btw-- are you sending compressed or uncompressed audio?
Uncompressed, 16 bit ints. Compression requires analysis, introducing extra latency. I'm not using it in practice yet, as I still have to find (or develop) a solution for packet loss concealment.
You might check out Opus.
http://en.wikipedia.org/wiki/Opus_%28audio_format%29
-Jonathan
As of now, I use a cheap work-around for wireless monitoring only: an FM 'stereo' transmitter and receiver. FM stereo does not send over two frequency channels, therefore audio quality is suboptimal, not suitable for regular PA situations. However it may be suitable for 'silent concert' experiments in small venues.
Onyx, is that an idea? Most cell phones do have an FM receiver. They only work with wired headset connected, functioning as antenna. As wired headsets can be cheap, just offer them for sale during the event. The good thing with FM is, it has zero latency. I got a LinexFM transmitter from here:
Rumors go that USA versions have higher transmission power than the ones sold in Europe.
Katja
Why not send FUDI to a box connected directly to the PA system?
The sound space is the headphone s.I want to use the digital sonic space to play in live. And there Afr so many smartphones in circulation that it is viable as a presentation platform now. And if it isn't. I can always connect to a speaker system normally.
-Jonathan
On Apr 26, 2013 10:08 PM, "katja" katjavetter@gmail.com wrote:
Hi Onyx,
What is your aim, do you want to entertain your (physically present)
audience via smart phones instead of PA system?
Actually it a sonic space I want to explore. To play to people on their own personal "bionic ear". Click and listen. The scope for experimentation intrigues me. Gestural binaural processing will be fun.
I have a similar quest pending: to send Pd audio from a wearable computer
over wireless to PA system. It's simpler than your purpose (because it does not involve an internet browser), but still complicated enough. So far I've learned that UDP is the preferred protocol for real time audio transmission, because it can go one way without the time-consuming error-checking and recovery.
I use UDP with the new wireless system I put together and it completely overhauled my latency. I think the new HTML 5 components for real-time audio will work since they are also primed for VoIP. I am also tweaking this shout cast server to buffer maybe 2-3kbps so I can try for a hoped for 100-300ms latency. I think it's just a matter of tweaking a few things. I am looking into possibly using mp3streamout to stream directly into a stream input in the browser itself, without any other code. I don't know how yet but everything I read makes me believe it is very doable to get 50 stable, low latency 128kbps mp3 streams at 1000ms or less.
Smart phones only do wireless, and wireless suffers a lot from packet
loss, and packet loss must be concealed with clever dsp routines. Besides that, there is the (in this case relatively minor) issue of clock drift between two sound card clocks. Even if you send audio between two computers with [udpsend~] / [udpreceive~] over an ad hoc (point to point) wireless network you'll notice these issues. Just try it with two laptops and you'll see what I mean to say (here's how to set up ad hoc wireless network: https://help.ubuntu.com/community/WifiDocs/Adhoc).
At this point, I'd rather have crackly-fast low quality sound, than ok-3 second lag-sound. Which of the audio network able objects work without a receive object?
Still I think that ad hoc networking would be the way to go for low
latency local wireless connection. It would not work with regular internet browsers though. A yet to design (Pd or Jack based) app would be required at the receiving end, which does packet concealment and clock drift compensation.
About clock drift compensation, Miller Puckette had a hint a while ago,
very probably referring to this article:
I will check that out. Thank you. Hope you are well.
Onyx
Katja
On Thu, Apr 25, 2013 at 4:14 PM, onyx@onyx-ashanti.com <
onyxashanti@gmail.com> wrote:
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 you.
cheers!
Onyx
-- www.onyx-ashanti.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
On 27/04/13 05:38, onyx@onyx-ashanti.com wrote:
On Apr 26, 2013 10:08 PM, "katja"katjavetter@gmail.com wrote:
Hi Onyx,
What is your aim, do you want to entertain your (physically present)
audience via smart phones instead of PA system?
Actually it a sonic space I want to explore. To play to people on their own personal "bionic ear". Click and listen. The scope for experimentation intrigues me. Gestural binaural processing will be fun.
I implemented a version of an idea that had been done several times in the past ... a silent disco, where there are two djs playing to wireless headsets over 2 different channels ... with all sharing the same physical space.
The result is quite fun, in our case it was in a public square and was all powered by people jumping onto bikes hooked up to alternators etc
(well - I did have quite a large battery in the circuit just to be sure it wouldn't all wind down and get boring, but we did generate enough power almost all the time)
Simon
-
august -
Charles Goyard -
IOhannes zmölnig -
Jonathan Wilkes -
katja -
Martin Peach -
onyx＠onyx-ashanti.com -
Phil Stone -
s p -
Simon Wise