[linux-audio-dev] Jack-udp

[Pieter Palmers]

Jordan wrote:

> Hello all. I don't really have any business asking, but I am more and 
> more interested in digital HD recording, and I have spent many hours 
> recently studying hardware, software, techniques, et cetera. I don't 
> really have the funds to create such a system, but it is fun to plan 
> it out, in case my church or someone else would be interested in such 
> a system in the future.
>
> The recent discussion of jack over networks has gotten me wondering a 
> few things.
> Here is my current fantasy rack setup:
> 1U: UPS
> 1U: KVM
> 2U: RAID
> 2U: Master/DAW
> 1U: Slave Recorder/Node
> 1U: Slave Recorder/Node
> 1U: Slave Recorder/Node
> 1U: Slave Recorder/Node
> 1U: Gigabit ethernet switch (all computers connected through it)
>
> Basically, all slaves would boot off of the RAID server (for easier 
> maintenance) into a cut-down Linux kernel, and will boot into 
> text-only mode, starting only the programs absolutely required to run 
> Ecasound. The slave node would begin recording when the master tells 
> it to, and all audio data would be sent to the RAID server. I am 
> thinking that each slave would be able to handle 8 channels of mono 
> input. All nodes would be equipped with the OpenMosix software, so 
> that they can assist the Master when they are not busy.

I think the usage of openmosix might be dangerous wrt bandwith. If I 
remember correctly, openmosix can generate a lot of ethernet traffic. I 
also thought that jack.udp works reliably only on rather 'unbusy' 
networks, so I wonder wat would happen when openmosix descides to 
migrate a process to another machine (hence generating peak traffic).

Regarding this topic and the previous topic on jack.udp sync: We at the 
freebob project had the idea of implementing a feature into our backend 
that would allow a PC to be used as a 'FreeBob' device. (FreeBob is a 
driver project for certain firewire based audio interfaces)

Using firewire as a transport layer for audio can solve some problems, 
mainly those of sync and QoS. The scenario I had in mind was something 
like you describe above, but using FW for the audio transport between 
machines.

The idea is still rather vague, but nevertheless...

Pieter