[PD] Audio streaming for 3 or more channels?

Bektur ph318 at yandex.ru
Thu Jul 31 20:00:31 CEST 2014 

Hello!

Just tried 5Ghz band with 802.11n standard. It worked much better than previous setup (2.4Ghz and 802.11g), in 3 tests around 10 minutes each I haven’t noticed any jitter or header tag errors.

Best regards,
Bektur

On Jul 31, 2014, at 6:30 AM, Julián Villegas <villegas.julian at gmail.com> wrote:

> 
> 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 at lists.iem.at wrote:
> 
>> Send Pd-list mailing list submissions to
>> 	pd-list at 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 at lists.iem.at
>> 
>> You can reach the person managing the list at
>> 	pd-list-owner at 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:
>> 
>>  1. Re: Audio streaming for 3 or more channels? (Bektur)
>>  2. Re: Audio streaming for 3 or more channels? (Martin Peach)
>>  3. Re: constantq~ - Thomas Grill (Federico Llach)
>> 
>> 
>> ----------------------------------------------------------------------
>> 
>> Message: 1
>> Date: Thu, 31 Jul 2014 00:37:19 +0600
>> From: Bektur <ph318 at yandex.ru>
>> To: pd-list at lists.iem.at
>> Subject: Re: [PD] Audio streaming for 3 or more channels?
>> Message-ID: <0399B37B-8F1F-404C-AA6B-0A3E07A38F24 at 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 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-0001.html>
>> 
>> ------------------------------
>> 
>> Message: 2
>> Date: Wed, 30 Jul 2014 15:05:20 -0400
>> From: Martin Peach <martin.peach at sympatico.ca>
>> To: Bektur <ph318 at yandex.ru>, pd-list at lists.iem.at
>> Subject: Re: [PD] Audio streaming for 3 or more channels?
>> Message-ID: <BLU436-SMTP12616689F419512EB6E7164EDF90 at phx.gbl>
>> Content-Type: text/plain; charset="UTF-8"; format=flowed
>> 
>> 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
>>> 
>> 
>> 
>> 
>> 
>> ------------------------------
>> 
>> Message: 3
>> Date: Wed, 30 Jul 2014 14:42:14 -0700
>> From: Federico Llach <federicollach at gmail.com>
>> To: Thomas Grill <gr at grrrr.org>
>> Cc: Dan Wilcox <danomatika at gmail.com>, pd-list at lists.iem.at
>> Subject: Re: [PD] constantq~ - Thomas Grill
>> Message-ID:
>> 	<CAMMYponWgC3rH8RXkGXVk0WNpJzFZz29_t9nzDSE3bEoGREukw at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>> 
>> Hi Thomas / hi all,
>> 
>> As a follow-up, plus a question: I was trying to get all of this installed
>> on another computer which is running on OS Mavericks but the "brew install
>> fftw --enable-sse2 --universal" command would only give me the 64 bit
>> installation, as checked with:
>> 
>>  $ lipo -info /usr/local/Cellar/fftw/3.3.4/lib/libfftw3.3.dylib
>>  Architectures in the fat file:
>> /usr/local/Cellar/fftw/3.3.4/lib/libfftw3.3.dylib
>> is: x86_64
>> 
>> I feel this is because Mavericks won't "allow" the 32 bit (?).
>> 
>> Constantq~ is giving the same "wrong architecture" message, which makes me
>> think it only runs in 32 bit, or "needs" the 32 bit version of the fftw
>> library.
>> 
>> So, is it possible at all to use constantq~ in a computer running on OS
>> Mavericks?
>> 
>> Thanks,
>> 
>> Federico
>> 
>> 
>> 
>> 
>> On Sun, Jul 13, 2014 at 9:54 PM, Federico Llach <federicollach at gmail.com>
>> wrote:
>> 
>>> Hi Thomas, hi all,
>>> This worked, finally got it running, thanks for the detailed explanation!
>>> All best!
>>> Federico
>>> 
>>> 
>>> On Fri, Jul 11, 2014 at 3:46 AM, Thomas Grill <gr at grrrr.org> wrote:
>>> 
>>>> 
>>>> Hi Frederico,
>>>> 
>>>> I think I have all the other necessary requirements (Python and Numpy)
>>>> but I am not sure:
>>>> - what version of the file I should download from
>>>> http://grrrr.org/data/dev/ext/macos/pd/ . I am running on Mac OS X Snow
>>>> Leopard 10.6.8
>>>> 
>>>> 
>>>> start the terminal program and run the following commands:
>>>> - "python —version“ - this will give you the version of your Python
>>>> installation
>>>> - „which python“ will give you the location of your python installation
>>>> 
>>>> The major Python version is important: 2.5, 2.6. oder 2.7
>>>> and whether it is a system package (sitting in /usr/bin) or a user
>>>> installed „local“ version (sitting in /Library/Frameworks/Python.framework)
>>>> 
>>>> That’s how you pick the py.pd_darwin-*.zip package. Unzip it and put it
>>>> into pd’s extra folder.
>>>> 
>>>> - where to locate the "binaries to load" in Pd-extended. I can only add
>>>> paths or "startup flags" but that hasn't worked—maybe I have the wrong
>>>> file? I include a screenshot of how my menu looks.
>>>> 
>>>> 
>>>> You’ll have to go to File/setup/startup flags and there add „-lib py"
>>>> 
>>>> good luck,
>>>> gr~~~
>>>> 
>>>> 
>>> 
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140730/c6936fb3/attachment.html>
>> 
>> ------------------------------
>> 
>> Subject: Digest Footer
>> 
>> _______________________________________________
>> Pd-list mailing list
>> Pd-list at lists.iem.at
>> to manage your subscription (including un-subscription) see
>> http://lists.puredata.info/listinfo/pd-list
>> 
>> 
>> ------------------------------
>> 
>> End of Pd-list Digest, Vol 112, Issue 63
>> ****************************************
> 
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

More information about the Pd-list mailing list