On Thu, 12 Nov 2009 09:11:48 +0100
Giso Grimm <gg3137@xxxxxxxxx> wrote:
> Hans Wilmers wrote:
> >>
> > I guess that jack is too big a burden for the small kind of system we
> > are talking about, so the question is, if netjack could be implemented
> > standalone - or maybe another suitable mechanism?
> >
>
> It should be possible to implement the netjack protocol also for a
> standalone application, but with that I would wait until there are
> decisions on the 'final' netjack version. The jack_netsource code is
> approximately 2000 lines of C code (including "netjack_packet.c", with
> CELT support and transport control).
>
> Since packet loss is probably not acceptable in a 'sound card', it may
> be worth to go for a TCP based solution. Also the clock protocol is not
> included in netjack.
>
> I see two different scenarios (OSHw = OpenSoundHardware, <---> audio
> transport, <===> audio and clock transport, <~~~> audio transport with
> drift control/resampling):
>
> a) netjack based solution, one OSHw, no clock protocol, no sync:
>
> alsa_{in,out} <~~~> jackd -dnet <---> OSHw
>
>
> b) own protocol, multiple OSHw, master clock:
>
> Master Clock
> Host sound card
> ||
> jackd <===> OSHw
> <===> OSHw
> <===> OSHw
>
>
> c) 'classical' sound card concept:
>
> ALSA driver <---> OSHw
> |
> ALSA driver <---> OSHw
> |
> ALSA driver <---> OSHw
>
>
> (ok, that is three). From a recording studio point of view I think that
> version (b) is the best. It would require to implement a driver which
> itself is a jack client. As a jack client it is platform independent.
>
> - Giso
A little bit of interest maybe.
It appears there is a software suite for the 'other' OSs that can
manage 16 channels of 48k over the Internet (not just a LAN) provided
you have an upstream of greater than 150Mbps and downstream better
than 750Mbps.
Also, there is a very useful looking fully self-contained Ethernet chip
that can deliver 25Mbps at application level. This is the WIZnet W5000.
It can also open up to 4 sockets, so I'm not clear as to whether that
is 25Mbps per socket, or in total.
Very empirically speaking, with 1 channel at 24 bit depth that's a
potential sample rate of 1MHz, or putting it another way 20 channels of
48k! OK, OK, I know I'm leaving out huge swathes of control, collisions
etc. :)
This chip can handle both TCP and UDP. From what little I know of the
protocols I would say that UDP would be the way to go. Everything
listens to anything on the network, and all recognition and
handshaking is done away from the network connection itself. This is
bound to reduce latency as well as reducing packet size.
Being a bit simplistic if you have a master clock (not necessarily
the computer) send just a timecode at 48kHz everything can lock on to
this immediately, and keep updating its copy of the timecode.
Something wanting to transmit audio would then send back it's own ID,
the current timecode followed by up to 24bits of A/D stream.
Packets would be small and latency low, buffer size could probably also
be quite small.
The computer would pick up all the incoming data streams and sort them
into their appropriate channels and time points. At this level, the
occasional out of sequence packet could probably be put back into it's
right place with only a relatively small additional buffer - well I
hope so!
This is all off the top of my head, so I won't be at all offended if
someone points out a simple flaw that brings the whole idea crashing to
the ground.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
