[PD] Audio streaming for 3 or more channels?

[Martin Peach]

Yes, I think WiFi is glitchy because of retransmissions by the radios in 
a noisy (other radios operating on same channel) or cluttered (lots of 
metal and concrete) environment. You may be able to get better WiFi 
performance by choosing another channel at the router.

Martin

On 2014-07-30 14:37, Bektur wrote:
> 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
> <mailto: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
>> <https://soundcloud.com/apolotary/multicast-glitch>
>>
>> Best regards,
>> Bektur
>>
>> On Jul 25, 2014, at 3:25 AM, Martin Peach <martin.peach at sympatico.ca
>> <mailto: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 <mailto: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 <mailto:Pd-list at lists.iem.at> mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>