I am trying to get either netsend~ or streamout~ to work. So far neither of them are working with their respective receive objects.

with netsend~ we're getting weird errors like sending too many channels, when we set it to 2. the error would say sending 47 channels or some other false information.

okay so here is the process

[format 8bit<
[connect xxx.xxx.xxx.xxx 8000<
compute audio

then on the receive side its says connected.
[env~] is reporting "nan"
then the boot
netsend~: send tag: software caused connection abort (10053)

with [streamout~] its reporting large numbers on the streamin side. Below is an example.

unknown format 0
unknown format 0
unknown format 0
unknown format 0
error: streamin~: got an invalid frame size of -large number, maximum is 256

[streamin~] is set with [reset 4<

any ideas, I would rather get netsend~ working as you can seemingly do multiple channels.

I don't think you can send audiostreams over an osc connection?

Btw, where can i get the [netsend~]/[netreceive~] objects, or the stream versions?

Thanx,

D.

Yeah domien is correct I am trying to send audio signals not just control messages. OSCSend works like a charm.

I grabbed netsend~ from here
http://www.nullmedium.de/dev/netsend~/

streamin~ was in extended at ../extra/ggext or ggex something close to that.

It might also be worth noting that the test-netsend~.pd patch that comes with the objects does work when you connect to the 'localhost'. I also got the error message,

netsend~: send tag: Broken pipe (37)

I'm able to connect to a networked computer, but I can't send any audio. draph and I are working on this together, and we're able to send and receive OSC messages on the same network setup.

Any suggestions?

just tried netsend~ works OK here (localhost).
I remember when itried it before 16bit was the most stable.
BTW if youre outside a local network i think you should look at the pdogg objs from Pd-extended.

In our tests we were able to connect to the localhost and process audio. We are on a local network, just two computers connected to a switch. The problem occurs when trying to send audio to each other's computer.

Okay so the next train of thought is that. i have an AMD Windows machine. hd is using an intel Apple. so the 'byte ordering' is wrong, some big/little endian stuff. i was looking at the netsend~ code and noticed it checks for whether its an apple or windows/linux machine but not powerPc or intel apple. can someone point out some other pd objects that do this so i can examine the code there. thanks.

still need to try intel to intel either both apple or both pc and other such similar connections

here this was on the pd list, i thought i'd post it to condense information

Somebody was just asking me about options for streaming audio and video in Pd-extended. I wouldn't mind help with the answer. Here's what I have gathered so far.

Audio:
streamin~ and streamout~ --- but the help patches don't seem to work in Linux. Seems to work ok in windows.
netsend~ and netreceive~ --- not provided in pd-extended and seemed a bit flaky when I tried them before.
mp3streamin~ and mp3streamout~ --- help patch missing in pd-extended but seem to work ok outside of Windows.
mp3cast~ and friends: seems to work ok if you have a shoutcast server...
Video:
I couldn't find anything in Gem to stream video. Did I miss it? I was wondering if using pix_pix2sig~, streaming as audio, then pix_sig2pix~ might work.
in pdp/pidip there's pdp_i and pdp_o. I didn't find help patches for these in pd_extended
also in pdp/pidip there's some other's pdp_mp4live~ etc. I suspect the ffserver-based ones don't work in pd-extended. Not sure on the others.
For either audio or video maybe there's a way to send to vlc through the stdin or stdout, then let vlc do the streaming?

Hello!

What about latency?

I'm very interested to use audio streaming over PD but I'm not sure if I can use it in order to perform real-time audio monitoring. For example... into a audio recording studio.

What do you think?
Someone tested it before?

I think the best way to do this will be using OSC, transmitting audio over OSC is theorically possible but I don't know how to do it.

Thanks a lot.

Hey guys,

It's a super old post but since the netsend~ and netreceive~ are old as well I thought to add my 2 cents here.

I ran into similar problems connecting a Linux desktop to a Raspberry Pi with netsend~ and netreceive~. My desktop cpu (x86_64) and the ARMv7 of the Raspberry have different word lengths (64bit vs. 32bit). The problem is that the header tag uses long datatype for the members count and framesize, which the compiler maps to the word length of the current architecture. Thus, the send and receive ends of the transmission interpreted a different sized header tag, causing strange error messages about too many channels and incompatible header size.

To fix it, I simply edited the file netsend~.h and changed the datatypes of the members from long to unsinged int (or to something that is guaranteed to stay as standard size like __u32 just to make sure). I also wonder if the array extension is necessary because if you order the larger datatypes first, the compiler seems to pad the overall size of the struct to 12 in both 64 and 32 bit machines.

typedef struct _tag {       /* size (bytes) */
    __u32 count;            /*    4         */
    __u32 framesize;        /*    4         */
    char version;           /*    1         */
    char format;            /*    1         */
    char channels;          /*    1         */
    //char  extension[5];   /*              */
} t_tag;                    /*--------------*/
                            /*   11         */

Btw, does anyone know if there is a more updated version of netsend~ and netreceive~ available since the 1.0b by Remu?