On Thu, Nov 26, 2009 at 08:55:50AM +0000, Folderol wrote:
On Thu, 26 Nov 2009 06:36:07 +0100
torbenh <torbenh(a)gmx.de> wrote:
On Tue, Nov 24, 2009 at 08:34:53PM +0100, Karl
Hammar wrote:
Florian Faber:
Karl Hammar wrote:
> [..ethernet transports..]
> And we are missing an open protocol for this.
What is wrong with netjack? It's made for point-to-point and very
simple. You just have to solve the clock issue unless you want to lose
bit transparency.
Ohh, sorry, I got the impression it was not ready. I don't mind being
wrong in that.
may i kindly ask what gave you that impression ?
i admit that some jack versions in svn were broken for the LAN use-case
because i am focussing on making it work for wireless and
transcontinental internet connections.
I'm not sure why, but I had an impression of 'unreadiness' too :o
:S great.
did you try it, and it didnt work ?
but the lan use-case it pretty trivial and doesnt
need all this deadline
machinery.
if you just want to build a network soundcard, and use jack on a
computer with that, its ready for 3 years now !!!
The remaining issue then is how much additional latency does netjack
introduce? I think, eventually, this will turn out to be the most
critical issue.
if you dont saturate the link, its one period.
you have the same problem with usb soundcards.
for 100Mbit the threshold where you need 2 periods, is somewhere around 12 channels.
having more than one network soundcard, and
keeping stuff in sync is
more tricky. it requires that you can control the wordclock on that
soundcard, and you need a special version of alsa_out.c
which instead of resampling controls the wordclock frequency.
If there is no internal sound card, why is there any need for alsa?
Wordlock may not be as difficult as it first seems. A bit I originally
wrote to LAU...
if you have a master clock, and want to adjust your output to this, then
the alsa_out program would be what you want.
it extracts the clock driving jackd, and is able to control a resampling
rate so that the phase is pretty constant.
Looking up the AES spec quickly reveals 48kHz +/-
10ppm. If the
card's master oscillator has that kind of stability, it would surely
require only very tiny slow adjustments to keep two of them in sync.
Worst case would be them consistently drifting the maximum allowance in
opposite directions, which if my maths is up to scratch results in
about a second before they would actually get out of step by 1 cycle.
A quick google reveals 5ppm temp compensated oscillators with a a 7ppm
voltage controlled pull-in - no idea how much these cost though.
Even without this, I wonder what the audible effect on real music would
be of just dropping one sample per second. It might be worth doing some
experiments to find out.
i dont understand why you want that...
It also occurs to me that although we want to lock
frequency, phase
relationship between cards is a red herring. Signals from different
sources will not have any phase relationship, so why should the cards?
alsa_out is able to deliver that.
--
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-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language