On Sun, Oct 05, 2014 at 08:39:11PM +0200, tom(a)trellis.ch wrote: Either 1. Sync the HW sample rates to an explicit or implicit reference provided by the network protocol. Requires special audio HW. A few normal audio interfaces (e.g. some RME cards) would allow to do this as well, but I know of no software that uses this capability.

2. Resample at the receiver, as njbridge does.

3. Use some other trick. E.g. for VOIP a classical one is to modify the lenght of the pauses between words or phrases.

The digital data is not the same, but it shouldn't be if your sample rate is not the same as the sender's. The analog signal will be the same, as if it was sampled by your HW.

Am Sonntag, 5. Oktober 2014, 23:35:21 schrieb tom(a)trellis.ch: just to add another options and be a wiseacre : On a microchip dsPIC [1] you can adjust the internal oscillator (RC) (where also the sample clock for DA is derived) in a small range of 10%, so it is possible to use PTP for sample-exact synchronization (I did do a "soft PLL" for a low cost solution of a DA to avoid re-sampling and big buffers). I was told on ARMs Oscillator tuning is also possible, and if audiohardware derives clocks from it, it can also be tuned and used as soft PLL.

Anyway there are Chips [2] which can generate sample-clocks (Master-Clock) from a PTP signal, so if your audiohardware supports Master-Clock, you can add such a chip ;-).

[1] http://ww1.microchip.com/downloads/en/DeviceDoc/39700c.pdf page 10 [2] http://en.wikipedia.org/wiki/List_of_PTP_implementations#silicon

http://www.rtnet.org/

Hi, i'm following the thread of the ongoing topics around transmitting audio over IP infrastructure. As a scenario, at point a) an analog signal is injected that will be played back (analog) at point b) with the lowest possible (and constant) latency. How do you intend to handle diverging clocks of the audio interfaces (ADC/DAC) at both (a/b) ends?

On Sun, October 5, 2014 22:51, Len Ovens wrote: ok, you can make the systems "in-sync" with PTP. but are there audio interfaces that can use the clock from the host? i.e. the host drives the audio interfaces clock.

On Sun, Oct 05, 2014 at 01:51:36PM -0700, Len Ovens wrote: It's easy to write in a standard that 'The media clock is then derived from that'. Doing it is another matter. It requires either controlling the HW sample rate (which is the 'media clock' for audio) or resampling.

On Sunday, October 05, 2014 08:47:25 AM Len Ovens wrote: "Enterprise" switchs have hardware support for the PTP protocol. The timing of PTP without hardware support in the switches is not 100% deterministic.

IGMP Snooping built into the switch is very convenient. Otherwise the multicast audio transport will flood your ports.

On Monday, October 06, 2014 04:10:59 PM you wrote: IGMP is the protocol used to solicit membership to a multicast group. IGMP snooping is the switch probing layer3 in order to monitor which ports have connections subscribed to multicast groups, and uses that to determine which multicast traffic should be sent to which port. Without IGMP snooping, the multicast traffic is sent to all ports, which makes it no different than broadcast traffic. And with multicast flooding all ports, you actually eat up more bandwidth than if you sent duplicate unicast traffic to multiple locations.

On Fri, 10 Oct 2014, Winfried Ritsch wrote: Am Sonntag, 5. Oktober 2014, 08:47:25 schrieb Len Ovens: This looks like the same idea I had in the begining. I may look farther when I have time. Prioritizing audio (RT) through the net and tunnelling the low priority packets through. It is nice to know I don't have to do all the work and there is already something like this out there. However, with todays NICs and switches, It would seem to me there really should be no collisions anyway. In order for there to be collisions, more than one nic needs to be feeding the same wire as in the days of 10M coax or with a hub. (I am not talking about wireless networks which do have collisions because they are all effectively on one wire or limited number of channels and have to deal with other interference as well.) With duplex NICs (all of them since before 100m) there are two lines for each NIC, tx and rx. The switch is a cpu with a number of NICs, each of which is duplex. The packet comes in, gets queued and then resent. Unless my understanding of switches is off base, I don't see room for collisions at all. I think using rtnet would be nice for a open source simple audio-card over It could be used in a more complex way as well... the point in all this was originally... That there are getting to be less audio IFs that Linux can use outside of USB ones because firewire interfaces are becoming rare. This becomes a problem for those using a laptop where there is no longer a slot to add an after market FW IF. USB AIs have some problems: - Drivers. The USB3 drivers seem to giving people with USB2 AIs trouble with some HW. A USB AI that works for one kernel version may stop working with it the next. - Clean USB ports. Finding a clean USB port that is not hubbed with some other inside the box device can be difficult. Generally there is only one port on any laptop that is clean and on it's own interrupt... where to plug the midi devcie? - While the i/os work to standard, USB audio devices often use non-standard interfaces for other functions like routing, mixing and other DSP kinds of things. So USB is out, FW is out... what is left as an interface all laptops (and desktops) have? Network seems to be it. Despite comments I have made about laptop makers perhaps opting only to provide wireless network, one of the real pluses for wired network is that it is much harder to listen to by unauthorized people and so it is likey to stick around. It is fast enough and generally has it's own IRQ. SO the idea of making an open audio IF using the NIC. Looking at other open HW projects, the cost is higher to DIY. Looking at the MOD DUO (which is funded BTW) it looks about 3 to 4 times as much as the Zoom box that does (to the guitarists eyes) the same thing. So looking at a good quality USB stereo IF at $100 to $150 and change that to $400 or more to build it yourself. There are already s/pdif IFs that are DIY. Generally they are either input or output. I do not get the idea they are cheap though. So while the idea of an open audio IF is a great idea still. It is not the answer for the small studio running open source SW looking for a Linux compatible AI. At least not short term. What does seem to be emerging are AoIP interfaces. They are not as cheap as some of the USB2 devices, but if they are reliable and the routing and mixing can be controled from Linux, This would be a good path forward. The only two PCIe audio IFs I know of that claim to have working Linux drivers are the RME (sort of) and the AudioScience cards (which use two drivers, ALSA for audio and another for DSP control). Both of them are ~$1k solutions for 8channels or so. The AoIP devices seem similar. This is where AES67 comes in. It looks like the near future will see most AoIP boxes support AES67. There are two ways to deal with these boxes: - a PCIe interface that looks like an audio card but connects to AoIP boxes. (AudioScience has one, with Linux driver, for Axia AoIP Livewire) - A native Linux AES67 driver. Both methods have uses. A native Linux driver will be a cost effective way to add an AoIP IF or two as an AI to a DAW. If I had an AoIP box that supported AES67, that would be where I would put my time. For a bigger setup where more than one computer may be involved or a high number of tracks, the PCIe card would probably be better. Livewire BTW, is now compatible with Ravenna, which claims to already work with AES67. New LiveWire products are fully Ravenna compliant. (new designs such as the xnode audio IF) The axia site seems to indicate that compatable means works with 24bits/48k/48samples/packet. Compliant means all Ravenna streams work. Axia says Livewire version 2.0 is Ravenna. ( http://www.axiaaudio.com/ravenna ) AES67 (Ravenna and Livewire too) is more broadcast oriented than recording studio. I don't know if anyone would care to comment on the quality of broadcast audio compared to recording studio. What I do see in broadcast is much more willingness to be open about what is inside and more support for Linux than in the "made for Mac" DAW community. There is still a place in Linux for "use what ya have". Those who wish to buy an AI for their Linux project may wish to buy something that is known to work. AoIP could be in that place with an AES67 linux driver. -- Len Ovens www.ovenwerks.net _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev(a)lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev

This looks like the same idea I had in the begining. I may look farther when I have time. Prioritizing audio (RT) through the net and tunnelling the low priority packets through. It is nice to know I don't have to do all the work and there is already something like this out there.

So USB is out, FW is out... what is left as an interface all laptops (and desktops) have? Network seems to be it. Despite comments I have made about laptop makers perhaps opting only to provide wireless network, one of the real pluses for wired network is that it is much harder to listen to by unauthorized people and so it is likey to stick around. It is fast enough and generally has it's own IRQ. SO the idea of making an open audio IF using the NIC.