Hi Bektur,
have you tried WIFI using a router at 5GHz? I’d be interested in seeing if that makes any difference.
Cheers,
Julián.
On Jul 31, 2014, at 6:42 AM, pd-list-request@lists.iem.at wrote:
Send Pd-list mailing list submissions to pd-list@lists.iem.at
To subscribe or unsubscribe via the World Wide Web, visit http://lists.puredata.info/listinfo/pd-list or, via email, send a message with subject or body 'help' to pd-list-request@lists.iem.at
You can reach the person managing the list at pd-list-owner@lists.iem.at
When replying, please edit your Subject line so it is more specific than "Re: Contents of Pd-list digest..."
Today's Topics:
- Re: Audio streaming for 3 or more channels? (Bektur)
- Re: Audio streaming for 3 or more channels? (Martin Peach)
- Re: constantq~ - Thomas Grill (Federico Llach)
Message: 1 Date: Thu, 31 Jul 2014 00:37:19 +0600 From: Bektur ph318@yandex.ru To: pd-list@lists.iem.at Subject: Re: [PD] Audio streaming for 3 or more channels? Message-ID: 0399B37B-8F1F-404C-AA6B-0A3E07A38F24@yandex.ru Content-Type: text/plain; charset="windows-1252"
Just a heads up, I tried using multiple [udpsend~] objects in different setups, and managed to reach stream playback with almost no interruptions (except occasional hiccup due to wireless network conditions)
The best performance was on a Windows machine, connected via LAN cable to Wi-Fi router, and data was further sent wirelessly to iOS clients running [udpreceive~] objects on libpd. Also, I should note that a LAN cable has tremendously decreased the amount of interruptions.
Best regards, Bektur
On Jul 25, 2014, at 3:49 PM, Bektur ph318@yandex.ru wrote:
I’ve tried the multicast option with same setup, but unfortunately I’m getting the same issue (bad header tag error and distorted sound).
Just out of curiosity I recorded the audio output I was getting
Best regards, Bektur
On Jul 25, 2014, at 3:25 AM, Martin Peach martin.peach@sympatico.ca wrote:
Looking through the source code of udpsend~ I don't think broadcast sends a different packet, I'll keep looking. Also note that multicast is supported. Have you tried that? It should be more efficient than broadcast. (udpsend-help has the messages used by [udpsend~] for multicast, udpsend~-help needs updating).
Martin
On 2014-07-24 14:46, Bektur wrote:
Thanks for the advice!
I’m sorry for the late reply, but I finally got my hands on a windows machine, and here’s what I got:
- The issue with bad header tag in case of a broadcast is still there, so at least it’s not related to platform-specific implementation
- I managed to make it work by creating a set of separate [udpreceive~] objects for each client and they work almost without any noticeable problems with sound
I wish I could use wired connection, but since my clients are mobile devices, so I have to go with Wi-Fi.
Just in case if someone else would be looking for this problem, I think jack.udp is another possible option (since IIRC netjack and jackport don’t have mobile implementations). However, for now libpd + [udpreceive~]/[udpsend~] work well in local wireless networks.
Best regards, Bektur
On Jul 21, 2014, at 11:06 PM, Martin Peach martin.peach@sympatico.ca wrote:
On 2014-07-21 12:50, Bektur wrote:
> I’m running a simple iOS application with libpd and udpreceive~ objects in the patch. The audio is sent from a computer with udpsend~ object, with only one channel currently being used. Whenever I stream to a single IP address everything works fine with almost unnoticeable latency. However, when I try to broadcast to multiple addresses in the network (as shown in udpsend~ help patch), I get two kinds of errors: > > – On OS X, block size >= 512 triggers “Message too long (40)” error. It happens only on OS X (tried the same patch on ubuntu, and this error didn’t reappear), one of the possible solutions I found was to use smaller block size, but in such case it would cause the second kind of error > > – On a client I get "udpreceive~: bad header tag (1)” error with incrementing numbers in the error. At first, I thought the libpd implementation was to blame, but it also happened when I run the same send and receive patches on two different computers running Pd-extended and connected over a local wireless network.
I haven’t found any workaround for this yet, but I’m planning to try reproducing these issues on a windows machine with ASIO drivers.
I suppose if you do it over a wired connection it will work better. Probably the WiFi is dropping packets and retransmitting, so things get out of sync. I don't know how broadcast UDP is implemented in WiFi, but I imagine it involves sending copies of the same packet to each receiver rather than a single packet addressed to multiple receivers.
Martin
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list