[PD] Audio streaming for 3 or more channels?

[Bektur]

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 at 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 at 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 at 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 at lists.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/20140731/71db64a9/attachment.html>