Hi Katja,
Regarding all this with... Digital clocks need to be synchronized to work together or else you will get clicks. As you have said it can be done in a driver or it can be done on-chip if your hardware has that feature. It does indeed add to the latency. On pro sound cards you would find word clock to sync cards together or possibly time code input/output for synchronising with video cameras. Consumer hardware does not have these features since most people wouldn't have any use for this. Some equipment can hold a very stable clock even after being disconnected from the others. This feature comes with added costs. Super expensive digital radio mics have a noticeable latency even though they are highly specialised equipment built to minimise this very latency. It's about 3ms for a good setup. Anyhow the lowest latency you will find is using analog wireless packs. The only point of digital radio mics is Hollywood can't probably cope with non-encrypted dialogues of your favourite TV series during the shoot. Don't go for the cheapest, and you might not need the high end. You can rent that stuff if it's not needed for such a long time. The Sennheiser e100 (gen3) is pretty decent for the price. That would be about 450~500€ for a kit.
There is a pro level audio-over-ethernet distribution system called ethersound. It's proprietary, but worth looking into. As with other digital format, there is a master clock somewhere in the system to which every one syncs. Once again digital converters are the main culprits when it comes to latency. http://www.ethersound.com/technology/overview.php
Cheers Pierre-Olivier
On 06/03/2013 12:41, katja wrote:
Netjack docs look promising. It binds Jack clients on the transmitter computer (called 'slave') to the sample clock on the receiver computer ('master'). Netjack supports transmission over wifi, and over internet (using the CELT codec). It is primarily designed for 'distributed music'. Here is a paper introducing Netjack:
http://www.google.nl/url?q=http://lac.linuxaudio.org/2009/cdm/Saturday/22_Ho...
For anyone using Pd on a mobile device as sound generator, Netjack could be a great way to deliver audio over wifi. For my purpose though, I still need access to the sound card at the transmitter side to capture audio from a mic. An audio rate conversion routine called AlsaInOut is provided with Netjack so you can use the slave's sound card for playback. However, this can not be used for capturing or monitoring, due to large processing delay. So, clock drift is the show stopper here.
Clock drift is not related to network transmission but to the slight differences in clock speeds of sound cards even if they are set to the same nominal sample rate. It also happens with two sound cards used together on one computer, like when using an USB mic for input and the system sound card for output. Core Audio can handle such a setup, but at the expense of increased and fluctuating latency. Jack can combine soundcards, but buffer under- or overruns are audible.
What is so hard about compensating clock drift? If it must be done in a theoretically correct way, pitch should not change so it will be a time stretching routine which will indeed introduce considerable latency. However, clock speeds often differ by a very small amount, like a factor 1/1000 or less. What if we just accept the pitch difference? You would get playback speeds like 1.001 or 0.999, perfectly acceptable for my purpose at least. This would greatly simplify the task of resampling.
Katja
On 3/5/13, Charles Goyard cg@fsck.fr wrote:
Hi,
see if netjack fills the bill :
Netjack is a Realtime Audio Transport over a generic IP Network. It is fully integrated into JACK.
When you transport Audio Signals over a Network, you will always have the problem, that two Computers are bound to two different Sample Clocks. The other Network Transports face the Problem of compensating for the drift between these Sample Clocks. This is very hard to do.
NetJack works around this problem, by syncing all Clients to one Soundcard. So there will be no resampling or glitches in the whole network. Packet loss is now also handled gracefully. By using the celt codec, its even possible, that single packet losses get masked by the Packet Loss Concealment Code.
https://github.com/jackaudio/jackaudio.github.com/wiki/WalkThrough_User_NetJ... https://github.com/jackaudio/jackaudio.github.com/wiki/WalkThrough_User_NetJ...
Cheers,
Charles