Hi everyone,
Can anyone recommend a sound streaming solution for Pd?
I have looked into [mp3cast~], but it doesn’t support more than 2 channels (and so does darkice it seems). I have also tried using [udpsend~] from mrpeach externals, but unfortunately I experienced some strange bugs over there as well.
Are there any other possible workarounds?
Thanks in advance, Bektur
On 2014-07-21 00:00, Bektur via Pd-list wrote:
Hi everyone,
Can anyone recommend a sound streaming solution for Pd?
I have looked into [mp3cast~], but it doesn’t support more than 2 channels (and so does darkice it seems). I have also tried using [udpsend~] from mrpeach externals, but unfortunately I experienced some strange bugs over there as well.
What strange bugs are in [udpsend~]? If you run jack, see: http://netjack.sourceforge.net/
Martin
On 07/21/2014 06:13 PM, Martin Peach wrote:
If you run jack, see: http://netjack.sourceforge.net/
or jacktrip: # aptitude install jacktrip
If you run jack, see: http://netjack.sourceforge.net/
or jacktrip: # aptitude install jacktrip
Both solutions seem like exactly what I was looking for, thanks a lot!
Here’s what I encountered (copied from one of my earlier letters in mailing list)
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.
Best regards, Bektur
On Jul 21, 2014, at 10:13 PM, Martin Peach martin.peach@sympatico.ca wrote:
On 2014-07-21 00:00, Bektur via Pd-list wrote:
Hi everyone,
Can anyone recommend a sound streaming solution for Pd?
I have looked into [mp3cast~], but it doesn’t support more than 2 channels (and so does darkice it seems). I have also tried using [udpsend~] from mrpeach externals, but unfortunately I experienced some strange bugs over there as well.
What strange bugs are in [udpsend~]? If you run jack, see: http://netjack.sourceforge.net/
Martin
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
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
- 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
minor correction, I created a [udpsend~] for each client separately
On Jul 25, 2014, at 12:46 AM, Bektur ph318@yandex.ru 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
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
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
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
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@yandex.ru mailto: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 https://soundcloud.com/apolotary/multicast-glitch
Best regards, Bektur
On Jul 25, 2014, at 3:25 AM, Martin Peach <martin.peach@sympatico.ca mailto: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 mailto: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 mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Bektur -
Bektur via Pd-list -
IOhannes m zmölnig -
Martin Peach