Giso Grimm:
...
> 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
I don't understand this figure. From what I understand, jack talks
with an alsa driver which talks to hw. And jackd -dnet talks with
another jackd on the "other" box, which talks with its alsadriver/hw.
> b) own protocol, multiple OSHw, master clock:
>
> Master Clock
> Host sound card
> ||
> jackd <===> OSHw
> <===> OSHw
> <===> OSHw
Should I interpret this as
jackd <==> alsa_special_netw_driver <= over the network =>
alsa_sp_driver <==> OSHw
or
jackd <==> special jack client <== over the network =>
other half of the special jack client, poss. incl. alsa driver <=> OSHw
?
> c) 'classical' sound card concept:
>
> ALSA driver <---> OSHw
> |
> ALSA driver <---> OSHw
> |
> ALSA driver <---> OSHw
How come the OSHw have an audio transport between each other, or do you
mean clock transport?
> (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.
Why not wait and se what the netjack people comes up with. My problem
is to have "any" hardware up and running. And if the netjack crew
solves the problem in the meantime, so much the better, and if not,
then we have something to debug on.
Regards,
/Karl
-----------------------------------------------------------------------
Karl Hammar Aspö Data karl@xxxxxxxxxxx
Lilla Aspö 148 Networks
S-742 94 Östhammar +46 173 140 57 Computers
Sweden +46 70 511 97 84 Consulting
-----------------------------------------------------------------------
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
