[PD] Audio streaming for 3 or more channels?
Julián Villegas
villegas.julian at gmail.com
Thu Jul 31 02:30:48 CEST 2014
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
> ****************************************
More information about the Pd-list
mailing list