• Audio
  • udpsend~ udpreceive~ on Bela?

Hi there!
any chance to compile these mrpeach externals?
https://github.com/pd-externals/mrpeach/tree/main/net

By the way, I can't find a list of PD objects installed by default on Bela. Doe's it exist anywhere?

I need to stream 4 channels over IP with ethernet and probably a router between two Belas.

thank you!

mrpeach externals if used wouldn't be real-time safe and so they would cause the audio thread to lose its real-time priority, causing underruns and forcing you to increase latency. Apart from that, you'll have the audio clocks drifting between the two boards, which means that some sort of resampling / resyncing would be needed. Can you achieve your purpose some other way? For instance, exchanging symbolic data instead of raw audio, or exchanging analog audio via the analog I/Os ? How far are the units between them?

thank you,
there is a dedicated RJ45 cable already installed in a building from top to floor, >20m I guess, maybe with router or hub in between. Then asymetric audio lines is not an option.

I obviously found this thread:
https://forum.bela.io/d/594-udp-audio-over-ethernet
This is what you mean by symbolic data? Doe's the example patch work?

I understand mrpeach externals doesn't work with RT. In this application, I need a 12 hours latency (the sound captured is played back as a stream with a 12 hours delay!), so 2048 samples is not a problem :-D. But maybe udpsend~ will have too many other issues, it is a bit outdated (13 years...)

    rph-r This is what you mean by symbolic data?

    No, by symbolic data I mean essentially MIDI or other messages, something that is not the full audio stream.

    rph-r Doe's the example patch work?

    Not sure :-)

    rph-r I understand mrpeach externals doesn't work with RT. In this application, I need a 12 hours latency (the sound captured is played back as a stream with a 12 hours delay!), so 2048 samples is not a problem :-D. But maybe udpsend~ will have too many other issues, it is a bit outdated (13 years...)

    Sounds like what you may need instead is writing to audio file and copy audio files between the boards: you wouldn't have enough RAM to make a 12 hour delay line anyhow, and what happens if the board storing the delayed signal in RAM shuts down in the 12 hour period? I'd recommend making small-ish (10 minutes?) sound files with [writesf~] on one board and read them with [readsf~] on the other board, always keeping in mind that to achieve seamless playback you need to send the [open( message a few hundreds ms in advance of starting to play or record. Then syncing between the two boards can happen via rsync and you can remove files after use on the destination board so that you don't fill up the SD card. You do need an SD card if you want to store hours of audio , as the 1GB available on the eMMC won't give you much recording time.

    If you use the dev branch of Bela, then you can send messages to [s bela_system] to execute commands such as rsync or rm, so you can do everything from within the patches. Alternatively, you can have a separate script running as a service to do that (see here).

    thank you, this is precious!!

    Let's go for rsync. It is obvious we don't have to stream here, so it is safer to do it this way.
    And yes, I was planning to divide the 12 hours in small parts. 10' would be 212MB, seems ok. Do you think SD cards are strong enough or an SSD would be a better choice? I mean it will be constantly in duty, and we have to guarantee the installation for at least 5 years (!).

    At 12 hours recording per day, that's about 15GB so you'll write a full 64 GB SD card every 4 days. That means that in 5 years you'll erase/write the SD Card about 456 times. That's not too bad, these things should last 10 thousand cycles at least. I'd recommend you get a decent quality SD card and maybe have a handful of spares already flashed, so that if anything bad happens within the 5 years - or more - you simply swap the SD card and are ready to go.