Hi, you definitely can stream between apps on the same computer. Regarding latency you have to measure, but there are basically three parameters regarding the latency in the case of Pd:
a) network latency (negligible for localhost)
b) hardware buffer size / Pd latency
c) [aoo_receive~] buffer size
On my Windows 7 laptop with an ASIO driver and 64 sample hardware buffer size and 5ms Pd latency, I can set the [aoo_receive~] buffer size down to 4-5 ms. On some other systems, you might get even lower. One of the use cases of AOO is certainly low latency audio streaming over local networks, especially over long periods of time (literally weeks or months, given that the devices have access to a NTP time server).
AOO does have a bit more latency than [pd~] because of the extra buffer in [aoo_receive~]. I think it rather depends what you need: [pd~] is slaved to the parent process, but provides sample accuracy. On the other hand, when you run a seperate Pd instance and pass audio with AOO, they are fully independent.
Give it a try and report back! Here's the latest snapshot (Just unpack the .dek archive): https://git.iem.at/cm/aoo/-/jobs/10983/artifacts/download
I'm currently working on a UDP punch hole server, so that people can easily create peer-to-peer-networks over the internet und jam together :-)
Christof
On 04.04.2020 13:21, Ingo wrote:
Is this going to work for something like streaming 2-4 synth voices from one patch to another one inside of one computer? If yes, will the latency be lower than using the [pd~] object or will it be the same or higher?
Thanks! Ingo
-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Winfried Ritsch Sent: Friday, April 03, 2020 12:40 AM To: Pd-List Subject: [PD] AoO Coming Out: Audio over OSC - Message based streaming solution goes public...
Hello,
Thanks Christof Ressi the old concept was rewritten and short-comes using the build-in network objects has been resolved and own networking code added. (see doku there for history and ideas)
(Note it is an alpha version, but beta should follow soon)
The feature list is huge, but mostly:
- it supports raw audio and opus audio codec: small latencies for playing together - long buffers for long range streams
- it supports time synchronous streaming and resend strategies overcoming packet loss and network weakness
- it monitors the connections quality and latencies
- it is prepared fot punch-hole connections trough firewalls and ...
...
This is also a Request for Comments:
get it - test it - use it - comment and report - to enhance it
Note: The development was done within the Streaming Project Reenactment for "Sonic projections" in the exhibition "Primal energies" from Bill Fontana - Kunsthaus Graz using the community "FunkFeuer Graz" network . ( All artwork in museums are closed except this one on the facade )
with a mix of Arm based streaming devices: the DIYasb it runs now stable for over a month all over Funkfeuer Graz.:
see also: https://git.iem.at/cm/diyasb
mfG Winfried
--
- ao.Univ.Prof. DI Winfried Ritsch
- ritsch@iem.at - http://iem.at/ritsch
- Institut fuer Elektronische Musik und Akustik
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171
--
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list