22 Mar
2005
22 Mar
'05
4:36 p.m.
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.
The master would boot into GUI mode, so that the operator wouldn't be
intimidated by learning Linux command line. The master would be able to
see the status of all slaves, and what each channel is doing. The master
would able to assign friendly names to each of the input channels (ie:
vocal 1, vocal 2, drums 1, bass, etc.). When the operator checks a box
at each channel, to indicate whether it should record or not (no point
in recording if nothing is plugged into it). The operator can also enter
a friendly name for the project. When the operator issues forth the
"BEGIN RECORDING!!!!" command, a directory is created on the server, and
all nodes begin recording. The all data is sent directly to the server,
then opened on the DAW from there.
The DAW operator would be able to record a live mix into a JACK-capable
recorder, such a ReZound, then burn it to CD. The operator would also be
able to back-up the project
(ie: all of the raw audio) to a data DVD.
So, I guess the question is, would this work?
-jordan
22 Mar
22 Mar
8:45 p.m.
On Tue, 2005-03-22 at 15:36 -0500, Jordan wrote:
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)
I think for what that would cost, you would be way better off just using
the 2U master/DAW and a 1U KVM, and get a 32 or 64 channel RME card. I
would also skip the RAID.
This also has a reasonable chance at being silent and portable.
I have thought a lot about building the perfect 2U or 3U portable
DAW/live effects unit (mostly the latter) because I don't expect laptops
to really be suitable for live use in the forseeable future. They are
built for an office, not a rock or jazz club. Anything that stops
working when someone falls on it or spills beer on it will never be
fully suitable for live use in my book.
Lee
23 Mar
23 Mar
5:01 a.m.
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
5:26 a.m.
On Wed, Mar 23, 2005 at 10:01:44 +0100, Pieter Palmers wrote:
>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.
...
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...
Well, its only vague in that its not implemented :) From a thoeretical
p.o.v. its well defined, as the slave PC's appear as firewire audio class
i/o devices to the master.
I've not been keeping track of developements on FreeBob very closely, but
when I asked about this someone thought this might not be that hard, I
guess it was :(
- Steve
10:41 a.m.
Pieter Palmers wrote:
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
wow!! i think that's a killer app!!!
the sync informations are encoded in the firewire protocol? i was
thinking that having the firebob protocol transported via IP(v6?) would
be even greater, mainly for two reasons:
as a laptop user i have an external audiocard (usb, or another pc with
some kind of audio transport) and an external disc for recording: my
firewire disk is indeed faster than the laptop internal's one.. there
is enough bandwidth if i use firewire for both disk and "live audio"?
the second: i dont know the state of firewire "networks", i see them as
point to point links (maybe i'm wrong), but with IP one can design
really complex and ad-hoc network topologies with a strong
infrastructure, maybe with firewire those things are harder to design...
one example i have in mind: i want to link two computers, the first is a
spare pc for audio input/output so i would keep here jackd running with
the audio card interface, then some jack-rack to put some compressors,
limiters to the input and one or more reverbs to output, so the other
pc, lodaed with softsynths is only building the sound, not "beautifying"
it..
what do you think?
wil
---
11:13 a.m.
the sync informations are encoded in the firewire
protocol?
The FireWire bus allows isochronous and asynchronous data transports.
The isochronous transport protocol contains sync information
and each participants which wants to send isochronous data has to
allocated resources at the bus resource manager. Max. 80% of the bus
bandwith can reserved for isochronous data
i was thinking that having the firebob protocol
transported via
IP(v6?) would be even greater, mainly for two reasons:
All participants on the bus have first to be configured in which way
they want to synchronize (threre are several ways to do so). This is one
of the main problems the FreeBob problems has to solve. This
configuration is also done over the FireWire bus.
[...]. there is enough bandwidth if i use firewire
for both disk and
"live audio"?
Yes, the disk is accessed over the asynchronous transport mode. Though
only 20% of the bandwith maybe be left for the disk.
daniel
1:05 p.m.
On Wed, Mar 23, 2005 at 10:01:44AM +0100, Pieter Palmers wrote:
Jordan wrote:
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.
what are the physical medium requirements and cable length limitations
of firewire?
--
Eric Dantan Rzewnicki | Systems Administrator
Technical Operations Division | Radio Free Asia
2025 M Street, NW | Washington, DC 20036 | 202-530-4900
CONFIDENTIAL COMMUNICATION
This e-mail message is intended only for the use of the addressee and
may contain information that is privileged and confidential. Any
unauthorized dissemination, distribution, or copying is strictly
prohibited. If you receive this transmission in error, please contact
network(a)rfa.org.
1:28 p.m.
what are the physical medium requirements and cable
length limitations
of firewire?
Max cable length for IEEE 1394a (max speed S400) is 4.5 meters but to be
on the save side only
4 meters should be used.
With IEEE 1394b (max speed S800) its up to 100 meters IIRC but depends
on the calbe type.
7213
days inactive
7214
days old
linux-audio-dev@lists.linuxaudio.org
8 comments
7 participants
participants (7)
-
Antonio "Willy" Malara -
Daniel Wagner -
Eric Dantan Rzewnicki -
Jordan -
Lee Revell -
Pieter Palmers -
Steve Harris