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