[PD] direct connection from pd to webrowser, low latency

[onyx@onyx-ashanti.com]

On Apr 26, 2013 10:08 PM, "katja" <katjavetter at 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:
>
> http://kokkinizita.linuxaudio.org/papers/adapt-resamp.pdf
>

I will check that out.  Thank you. Hope you are well.

Onyx

>
> Katja
>
>
>
>
> On Thu, Apr 25, 2013 at 4:14 PM, onyx at onyx-ashanti.com <
onyxashanti at 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 at iem.at mailing list
>> UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130426/9e3924ae/attachment.htm>