[LAD] media clock from wall clock
I have been playing with numbers (a little) for AoIP and AES67 (because I can actually read the spec). The media clock (AKA wordclock) is derived from the wall clock which is synced via PTP. There are 3 sample rates supported 44.1k (not sure if any physical devices really do), 48k and 96k. The first thing I find is that it is not possible to get even word clock via simple math. The wall clock moves one tick per usec which at 48K is 20.833rep. (44.1k is a mess) I would suggest this is why AVB and AES67 at lowest latency already uses 6 sample frames which is a nice even 125 usec. It is obvious to me from this, that the true media clock is derived by external circuitry. The one "must support format" is 48k at 48 samples/packet. (both 16 and 24bit on the receive end of a stream) This is 1ms packet time. (there are AoIP devices that only support AES67 with this format) So I am guessing that it must be easy to derive a media clock from a 1ms clock input. The computer (CPU board) would have a GPIO with a 1ms clock out derived from the cpu wall clock which in turn is kept in sync with the network via PTP. I am guessing there is already a chip in production that does this with almost no support circuitry. The side effect of the 1ms/packet standard is that streams are limited to 8 channels at 48K and 4 channels at 96k. So for more channels more streams are required. This maximum comes from the limit that the full packet must fit into one standard ethernet packet with the MTU at 1500 (minus headers etc.). The transport does not do packet reassembly of fragmented packets and basically drops them. 1 ms latency in the jack world is the same as 16/3. This may explain why /3 works better for other formats such as USB or FW. It may also be the bridge that works best with OPUS at 5 ms. -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Lars Luthman
Is anyone in contact with Lars? I tried to send him an email but it immediately bounced, so i think I've got an address that's no longer valid. -- 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@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] media clock from wall clock
On Sun, Oct 12, 2014 at 08:50:31AM -0700, Len Ovens wrote: > The first thing I find is that it is not possible to get even word > clock via simple math. The wall clock moves one tick per usec which > at 48K is 20.833rep. (44.1k is a mess) I would suggest this is why > AVB and AES67 at lowest latency already uses 6 sample frames which > is a nice even 125 usec. This is a non-problem. A PLL/DLL (which is what any system that syncs one clock to another will amount to) can be made for any ratio of integers. The real problem here (but it's not a new one, solutions for this have been known for a long time) is a different one. If the media clock is to be used for actual AD/DA conversion (and oterwise you don't need it) it needs to have very low jitter aka phase noise. When you multiply a frequency by a factor of N then within the BW of the control loop the phase noise density will be multiplied by N^2. So you need a PLL/DLL with a very low BW. Which normally means that the capture range will be very small as well, and the loop may never lock for typical initial conditions. As said there are solutions for this, but you need to design for it. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] build problem with ambix plugins + LV2
Hi Matthias, I'm trying to build your ambix plugin suite on Linux using the LV2 wrapper, which fails with the following problem during makefile generation: CMake Error at CMakeLists_subprojects.txt.inc:104 (ADD_LIBRARY): Cannot find source file: /local/build/ambix/JUCE/modules/juce_audio_plugin_client/LV2/juce_LV2_Wrapper.cpp Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx Call Stack (most recent call first): ambix_binaural/ambix_binaural/CMakeLists.txt:20 (INCLUDE) It seems that the JUCE tree in your repo does not have an LV2 directory at all, and neither has the official JUCE repo - has it been dropped? Any hints much appreciated, best greetings from Essen to Vilnius, Jörn -- Jörn Nettingsmeier Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487 Meister für Veranstaltungstechnik (Bühne/Studio) Tonmeister VDT http://stackingdwarves.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] media clock from wall clock
On Sun, 12 Oct 2014, Fons Adriaensen wrote: On Sun, Oct 12, 2014 at 08:50:31AM -0700, Len Ovens wrote: The first thing I find is that it is not possible to get even word clock via simple math. The wall clock moves one tick per usec which at 48K is 20.833rep. (44.1k is a mess) I would suggest this is why AVB and AES67 at lowest latency already uses 6 sample frames which is a nice even 125 usec. This is a non-problem. A PLL/DLL (which is what any system that syncs one clock to another will amount to) can be made for any ratio of integers. In HW it is a non-problem. I am not so sure that is true in SW on a machine that is also running a DE, and a DAW on top of that. That is, I think that a cpu that has nothing to do but make a media clock would have no problem doing this. The real problem here (but it's not a new one, solutions for this have been known for a long time) is a different one. If the media clock is to be used for actual AD/DA conversion (and oterwise you don't need it) it needs to have very low jitter aka phase noise. That all makes sense. My thought is that because it would only be needed to sync codec HW, the PLL/DLL would best be done within the same HW as the codec rather than trying to do the same thing in SW. When you multiply a frequency by a factor of N then within the BW of the control loop the phase noise density will be multiplied by N^2. So you need a PLL/DLL with a very low BW. Which normally means that the capture range will be very small as well, and the loop may never lock for typical initial conditions. As said there are solutions for this, but you need to design for it. OK, that makes sense. I understand the basic idea of the pll and reading about the dll, I can see how that works too. I am guessing that the reason that AES3 can have such a wide range of capture is that it is already at the right frequency... or higher. (AES3 capture is often from 32k to 96k) So the jitter is the same as the source? -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
