Re: [LAD] AVB not so dead after all
On Tue, 21 Jul 2015, Thomas Vecchione wrote: Related to this topic, I would recommend reading through this... https://groups.google.com/forum/#!topic/theatre-sound-list/WbysqMHs6iw AVB isn't dead no, but it certainly isn't close to dominant at this point, at least on my side of the pond. It may be a different situation on the other side, no idea. That being said, it has a very uphill battle to displace Dante at this point on my side of the pond and get decent usage professionally. You are exactly right. However, for most of us, it is a matter of what can work with Linux and has open drivers. Right now nothing. The chances of some Dante box having a linux OS in it is probably quite high, but I can't even buy a closed version at this point (though I hear there are some around). And the HW to go with such a driver is not cheap (at least not cheap enough for me to buy when it may never work). Then again if AES67 interoperability comes into play, then is may be a moot point as ideally you would be able to communicate between the two protocols. AES67 right now is the same. There are no Linux drivers and none in the works so far as I know. There are some audio cards that are basically AES67 ends, but again they are not cheap. AVB is far from dominant for sure, but there is an open driver (well sort of... a group of bits that can be put together to make things work is more like it) in the works. It does require some special HW, but the gist of the thread is that the cost of that HW has come within reach. In other words, the average experimenter with no backing can start to tinker. There is an option to still make use of AVB equipment if one can't make this work, not cheap ($600) but similar to a USB AI with the same feature set that will act as either a USB (USB2.0 compliant it says) AI with AVB bridging or as an AVB AI. SO not a loss if things don't go well or not unusable while working on things. The internals can be controled via a web browser on the avb port even with no AVB stuff attached. Along with this, parts of the linux AVB driver and HW needed (the NIC for example) will be usable for AES67 development if someone chooses to do that. So AVB development may not seem like the best way to go, but right now it is the only way that at least seems open and in the end seems to also have the edge quality wise (perhaps that is debatable... I won't bother arguing either way). So for me, it is about accessability. I am a hobbiest (at this point anyway) and Dante/AES67/Ravenna are out of my reach. AVB seems to have entered into that accessable place. One thing I will say is that Dante and AVB can coexist on the same network, it should not be very hard to make a box with only one NIC that can bridge the two... and make whatever in on one protocol look like it is on the other. -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AVB not so dead after all
Related to this topic, I would recommend reading through this... https://groups.google.com/forum/#!topic/theatre-sound-list/WbysqMHs6iw AVB isn't dead no, but it certainly isn't close to dominant at this point, at least on my side of the pond. It may be a different situation on the other side, no idea. That being said, it has a very uphill battle to displace Dante at this point on my side of the pond and get decent usage professionally. Then again if AES67 interoperability comes into play, then is may be a moot point as ideally you would be able to communicate between the two protocols. Seablade On Mon, Jun 15, 2015 at 7:05 PM, Len Ovens l...@ovenwerks.net wrote: Looking at the MOTU AVB endpoints, I see MIDI ports on them. None of the AVB docs I have read (yet) show MIDI transport. Is this then just RTP-MIDI on the same network? It almost seems that the midi is visible to the USB part only. Motu recommends connecting one of the AVB boxes to the computer via USB or Thunderbolt and streaming all avb channels through that connection. So this would mean that the BOX closest to the computer is the audio interface. With Thunderbolt the maximum channel count is 128 with any mix of i/o from that (example 64/64 i/o). Connection to the computer via AVB: http://www.motu.com/avb/using-your-motu-avb-device-as-a-mac-audio-interface-over-avb-ethernet/ shows some limitations: - SR can be 48k and multiples but not 44.1k and multiples - The Mac will insist on being the master clock - The Mac locks each enabled AVB device for exclusive access. (The mac can talk to more than one AVB device but they can't talk to each over or be connected to each other while the Mac has control) - Maximum channels is still 128 at least on a late 2013 Mac Pro. earlier models should not expect more than 32 total channels (mix of i/o) - Motu AVB devices set all streams to 8 channels, no 2 ch streams allowed. - Because the AVB network driver on Mac looks like a sound card, Audio SW needs to be stopped before changing channel counts. (adding or removing IF boxes) I think that a Linux driver has the potential to do better in at least some cases. I personally would be quite happy with 48k SR only, but I am sure someone will make it better. Linux does not have to be the Master Clock unless it must sync to an internal card that only has some kind of sync out but can't lock to anything (like some of the on board AIs that have a s/pdif out). In the Linux case, the AVB AI may well be the only used AI and the internal AI can't be synced to anyway. With Jack, channels can come and go with no ill effect except a connection vanishes. Channels can be added and removed even within a jack client. This _should_ (logically) be possible in a Jack backend, but maybe not wise. A sync only backend may be better that takes it's media clock from the AVB clock as this would add stability in case of an avb box being disconnected. I do not know if jack backends can deal with 0 or more channels with their number changing, but a client dying because it's remote AI vanished would not crash jack. The problem with using clients for the AI is that auto-connecting APPs look for system/playback_1 and _2. Even more jack aware apps like Ardour would have you looking in other for more inputs. Anyway, getting AVB working with Linux is first (even two channels). -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AVB not so dead after all
Looking at the MOTU AVB endpoints, I see MIDI ports on them. None of the AVB docs I have read (yet) show MIDI transport. Is this then just RTP-MIDI on the same network? It almost seems that the midi is visible to the USB part only. Motu recommends connecting one of the AVB boxes to the computer via USB or Thunderbolt and streaming all avb channels through that connection. So this would mean that the BOX closest to the computer is the audio interface. With Thunderbolt the maximum channel count is 128 with any mix of i/o from that (example 64/64 i/o). Connection to the computer via AVB: http://www.motu.com/avb/using-your-motu-avb-device-as-a-mac-audio-interface-over-avb-ethernet/ shows some limitations: - SR can be 48k and multiples but not 44.1k and multiples - The Mac will insist on being the master clock - The Mac locks each enabled AVB device for exclusive access. (The mac can talk to more than one AVB device but they can't talk to each over or be connected to each other while the Mac has control) - Maximum channels is still 128 at least on a late 2013 Mac Pro. earlier models should not expect more than 32 total channels (mix of i/o) - Motu AVB devices set all streams to 8 channels, no 2 ch streams allowed. - Because the AVB network driver on Mac looks like a sound card, Audio SW needs to be stopped before changing channel counts. (adding or removing IF boxes) I think that a Linux driver has the potential to do better in at least some cases. I personally would be quite happy with 48k SR only, but I am sure someone will make it better. Linux does not have to be the Master Clock unless it must sync to an internal card that only has some kind of sync out but can't lock to anything (like some of the on board AIs that have a s/pdif out). In the Linux case, the AVB AI may well be the only used AI and the internal AI can't be synced to anyway. With Jack, channels can come and go with no ill effect except a connection vanishes. Channels can be added and removed even within a jack client. This _should_ (logically) be possible in a Jack backend, but maybe not wise. A sync only backend may be better that takes it's media clock from the AVB clock as this would add stability in case of an avb box being disconnected. I do not know if jack backends can deal with 0 or more channels with their number changing, but a client dying because it's remote AI vanished would not crash jack. The problem with using clients for the AI is that auto-connecting APPs look for system/playback_1 and _2. Even more jack aware apps like Ardour would have you looking in other for more inputs. Anyway, getting AVB working with Linux is first (even two channels). -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AVB not so dead after all
On Sat, 13 Jun 2015 11:31:07 -0700 (PDT) Len Ovens l...@ovenwerks.net wrote: On Sun, 7 Jun 2015, Jesse Cobra wrote: Just a few notes, not sure if this is of any use: Motu and Presonus are now shipping some semi-affordable AVB audio devices and switches. The Motu switch is $295. Here is an even cheaper switch: http://www.dsp4you.com/products/avb-oem-series/avb-sw It is not Gb, just 100M, but less than half the price and possibly good enough for testing, development, smaller channel counts (32ish?) It appears that at the same time as being a switch it could also be set up as an endpoint. There is I2S connections on it. So it could be a good starter set up with switch and 8audio i/o. I think, the spec just says: Internal 20pin 0.1” pitch connector with TDM/I2S input output streaming AVBTP (IEEE 1722) talker listener mode Up to 8ch per stream Sample rate of 44.1/48/88.2/96/176.4/192kHz Sample width of 20/24bit Automatic hardware locking to stream’s media using the IEEE 1722 presentation time And last of all, This looks like a ready to run AVB interface that will work on Linux: http://www.dsp4you.com/downloads/AV2USB%20Datasheet.pdf I could not find the price though. It is limited to 8/8 i/o and looks to Linux as a class compliant USB 2.0 8channel audio card. Of course those 8 channels can be any of the available AVB channels on the AVB network. More than one of these could be used on the same computer for 16 channels (or more) as they are by default synced. I would suggest a variant of zita-a2j with no resample to connect 2nd and more units rather than making a multi-device. This would allow plugging and un-plugging without stopping jackd. Also, if your internal AI has external sync capability (s/pdif or word clock) it could be used by the jack back end and av2usb boxes added as clients if at least one of the AVB audio IF boxes had a similar sync out. This may also be an inexpensive way of using network for audio transport from one computer to another in the same LAN with low latency. Two ethernet ports means a switch may not be needed. (aside from audio streaming a net port would be needed to control routing too unless that is somehow incorperated in the USB line) -- Len Ovens www.ovenwerks.net Better and better :D I don't suppose anyone has written an AVB - jack module? -- 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] AVB not so dead after all
On Sat, 13 Jun 2015, Will Godfrey wrote: I don't suppose anyone has written an AVB - jack module? https://github.com/audioscience/Open-AVB Does in fact list both a jackd listener and talker in their examples. The talker looks like it is more complete and would be able to run waiting for a listener to be connected. The listener expects the talker to be ready to send and will die if the talker is not there... so it would be best started by a connection application that knows what is there. In the end, the Linux community would probably be more thankful for an ALSA module. I think a Jack client would be easier to write though and actually makese more sense in an ecosystem where connections come and go and connections can go anywhere. Just found: https://github.com/audioscience/avdecc-lib Which is a lib for IEEE1722.1 (AVB Device Enumeration, Discovery and Control) that comes with a commandline controller. This allows Linux to discover and control AVB end points... That is make connections. At least a GUI cross point style control application would be very nice. But at least the CLI utility would allow things to be usable. An application like Qjackctl, Patchage or Ardour's Audio Connection Manager that covered both internal jackd connections as well as external AVB connections where an AVB jack client is started at connection time would be nice. It looks like it would be possible with just the libs and utilities listed here already. I'll see how far I get when I have some HW to play with. I am sure I have made it sound too easy by far. -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AVB not so dead after all
Here is an even cheaper switch: http://www.dsp4you.com/products/avb-oem-series/avb-sw I think I have one of these around here as well from an old project. I will send it along with the xmos endpoints! I should have a few Marvell firefox and apx 2 AVB eval kits kicking around I will look for... Also, the AVB community is starting to call it TSN (time sensitive networks)... ;) On Sat, Jun 13, 2015 at 1:14 PM, Len Ovens l...@ovenwerks.net wrote: On Sat, 13 Jun 2015, Will Godfrey wrote: I don't suppose anyone has written an AVB - jack module? https://github.com/audioscience/Open-AVB Does in fact list both a jackd listener and talker in their examples. The talker looks like it is more complete and would be able to run waiting for a listener to be connected. The listener expects the talker to be ready to send and will die if the talker is not there... so it would be best started by a connection application that knows what is there. In the end, the Linux community would probably be more thankful for an ALSA module. I think a Jack client would be easier to write though and actually makese more sense in an ecosystem where connections come and go and connections can go anywhere. Just found: https://github.com/audioscience/avdecc-lib Which is a lib for IEEE1722.1 (AVB Device Enumeration, Discovery and Control) that comes with a commandline controller. This allows Linux to discover and control AVB end points... That is make connections. At least a GUI cross point style control application would be very nice. But at least the CLI utility would allow things to be usable. An application like Qjackctl, Patchage or Ardour's Audio Connection Manager that covered both internal jackd connections as well as external AVB connections where an AVB jack client is started at connection time would be nice. It looks like it would be possible with just the libs and utilities listed here already. I'll see how far I get when I have some HW to play with. I am sure I have made it sound too easy by far. -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AVB not so dead after all
On Sat, 13 Jun 2015, Jesse Cobra wrote: Also, the AVB community is starting to call it TSN (time sensitive networks)... ;) As happens, searching for TSN gives many hits for a Sports network... I was looking for what the T was for, but it apparently is just The. AVB is much more searchable, I hope it sticks around as TSN(AVB) or something. I feel about as safe with a network controlled automotive braking system as an MS inspired automotive engine control computer. -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AVB not so dead after all
On Mon, 8 Jun 2015 12:04:55 +0200 Leonardo Gabrielli l.gabrie...@univpm.it wrote: Hello Reuben, I have been talking to a Intel guy at the last AES convention and he told me they are supporting AVB (maybe he's reading this list as well). Another strong signal regarding AVB not dead. We were specifically talking about audio networking and multimedia. Best Very interesting, and very pleased to see this. -- 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] AVB not so dead after all
Again if anyone wants an XMOS AVB sound card http://www.xmos.com/products/reference-designs/avb-lc I have a few I am not using. Also this is under $100, I have at least one of these I am not using. http://www.dsp4you.com/products/avb-oem-series/avb-dg On Jun 9, 2015 8:42 AM, Will Godfrey willgodf...@musically.me.uk wrote: On Mon, 8 Jun 2015 12:04:55 +0200 Leonardo Gabrielli l.gabrie...@univpm.it wrote: Hello Reuben, I have been talking to a Intel guy at the last AES convention and he told me they are supporting AVB (maybe he's reading this list as well). Another strong signal regarding AVB not dead. We were specifically talking about audio networking and multimedia. Best Very interesting, and very pleased to see this. -- 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AVB not so dead after all
On Tue, Jun 09, 2015 at 08:48:30AM -0700, Jesse Cobra wrote: Again if anyone wants an XMOS AVB sound card http://www.xmos.com/products/reference-designs/avb-lc I have a few I am not using. To those who are interested: that's cool stuff, you can just connect audio via RCA or 3.5mm jack, a network cable and you're good to go. Also features I2S sockets. Also this is under $100, I have at least one of these I am not using. http://www.dsp4you.com/products/avb-oem-series/avb-dg That's actually pretty neat: 8ins/8outs via AVB for $90. Of course, you only get an I2S socket, but that's exactly what you need to connect it to an ADC/DAC. Now if I only had time... ;) -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AVB not so dead after all
On Tue, 9 Jun 2015 18:40:04 +0200 Adrian Knoth a...@drcomp.erfurt.thur.de wrote: On Tue, Jun 09, 2015 at 08:48:30AM -0700, Jesse Cobra wrote: Again if anyone wants an XMOS AVB sound card http://www.xmos.com/products/reference-designs/avb-lc I have a few I am not using. To those who are interested: that's cool stuff, you can just connect audio via RCA or 3.5mm jack, a network cable and you're good to go. Also features I2S sockets. Also this is under $100, I have at least one of these I am not using. http://www.dsp4you.com/products/avb-oem-series/avb-dg That's actually pretty neat: 8ins/8outs via AVB for $90. Of course, you only get an I2S socket, but that's exactly what you need to connect it to an ADC/DAC. Now if I only had time... ;) Exactly! I think I'd need to clone myself half a dozen times to play^H^H^H^H work with all this fascinating stuff. -- 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] AVB not so dead after all
On Mon, 8 Jun 2015, Fernando Lopez-Lezcano wrote: An Intel I210 Gigabit Ethernet PCI express Card will set you back about $70 on Newegg, it does have the hardware support that AVB needs and a driver in the OpenAVB project. I have a couple and they seem to work just fine. A 24 output AVB Motu box is $995. The Intel I210 Gigabit Ethernet PCI express Card has gone up they are $90 now, but still reasonable. ( this one? http://www.newegg.ca/Product/Product.aspx?Item=N82E16833106176 ) This one says it has the same chip for only $50: http://www.newegg.ca/Product/Product.aspx?Item=N82E16833316879 This one (at $30) I might stay away from: http://www.canadacomputers.com/product_info.php?cPath=27_1048_1052item_id=55856U It says it is an Intel I210T1 Comp. The comp. meaning compatible. It actually has the intel 82574 in it not the I210T1. The Intel documentation does not mention AVB support as it does for the above cards. The intel card at the top looks like it has a coax connector on the board. The intel site does not make any mention of it though. The I210 chip does have 4 GPi/o, I wonder if it is connected to one of these (can be made to provide word clock or a multiple). Though I would guess it defaults to PPS? I'm actually trying to get this going with one of these AO24 Motu The MOTU UltraLite AVB looks more interesting to me. 10/10 i/o with midi. A bit cheaper ($700), can still get an extra 8 i/o with adat. But yes the price is getting managable. soundcards (starting with OpenAVB). I have gotten as far as the OpenAVB stack talking to the Motu card and slaving its clock to it (and the Motu box recognizing it is now the master clock source and AVB is active). Audio streaming is next, I'm just not finding the free time to do this (anyone gotten further along on this??). For me, even $700 is not cheap. The ethernet card or two is a possibility. For as far as you have gotten, what is the cpu load like? Does it affect the DSP load as jack shows it while jack is connected to the internal card at low latency? First goal would be a simple jack client that can stream samples, end game would be a jack backend so this can be treated as a soundcard. We'll see... The jack client should work with a PCI(e) card that has word clock in or spdif in. In my case I could use the spdif out to sync my internal card. This would sync jack to the MOTU (or other AVB device). This is (so far) sounding cheaper than any other AoIP aside from netjack. Netjack is fine for connecting two computers but not so much for adding inputs. It is also sounding more like there is some movement with it in the linux world. In any case an ethernet card is the first step. -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AVB not so dead after all
On 06/07/2015 07:15 AM, Len Ovens wrote: ... Why is this? Linux is based on lowest common denominator hardware... we call it the PC. The Linux world has gotten much better preformance out of this box than it was designed for. But, in the case of audio, the HW does limit performance at least with AoIP. That limit is the clock. The PC does not have a HW PTP clock built in and in this case software is not good enough. The way around this is with a custom NIC that does. For some reason even though one can buy an ethernet chip that includes a stable PTP clock for less than $5, any NICs I have found with a PTP clock are closer to $1k. An Intel I210 Gigabit Ethernet PCI express Card will set you back about $70 on Newegg, it does have the hardware support that AVB needs and a driver in the OpenAVB project. I have a couple and they seem to work just fine. A 24 output AVB Motu box is $995. I'm actually trying to get this going with one of these AO24 Motu soundcards (starting with OpenAVB). I have gotten as far as the OpenAVB stack talking to the Motu card and slaving its clock to it (and the Motu box recognizing it is now the master clock source and AVB is active). Audio streaming is next, I'm just not finding the free time to do this (anyone gotten further along on this??). First goal would be a simple jack client that can stream samples, end game would be a jack backend so this can be treated as a soundcard. We'll see... -- Fernando ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AVB not so dead after all
Sounds awesome Fernando. I have a few of the XMOS AVB endpoints I am not using if anyone wants one. On Mon, Jun 8, 2015 at 7:14 PM, Fernando Lopez-Lezcano na...@ccrma.stanford.edu wrote: On 06/07/2015 07:15 AM, Len Ovens wrote: ... Why is this? Linux is based on lowest common denominator hardware... we call it the PC. The Linux world has gotten much better preformance out of this box than it was designed for. But, in the case of audio, the HW does limit performance at least with AoIP. That limit is the clock. The PC does not have a HW PTP clock built in and in this case software is not good enough. The way around this is with a custom NIC that does. For some reason even though one can buy an ethernet chip that includes a stable PTP clock for less than $5, any NICs I have found with a PTP clock are closer to $1k. An Intel I210 Gigabit Ethernet PCI express Card will set you back about $70 on Newegg, it does have the hardware support that AVB needs and a driver in the OpenAVB project. I have a couple and they seem to work just fine. A 24 output AVB Motu box is $995. I'm actually trying to get this going with one of these AO24 Motu soundcards (starting with OpenAVB). I have gotten as far as the OpenAVB stack talking to the Motu card and slaving its clock to it (and the Motu box recognizing it is now the master clock source and AVB is active). Audio streaming is next, I'm just not finding the free time to do this (anyone gotten further along on this??). First goal would be a simple jack client that can stream samples, end game would be a jack backend so this can be treated as a soundcard. We'll see... -- Fernando ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AVB not so dead after all
Hello Reuben, I have been talking to a Intel guy at the last AES convention and he told me they are supporting AVB (maybe he's reading this list as well). Another strong signal regarding AVB not dead. We were specifically talking about audio networking and multimedia. Best -- Leonardo Gabrielli, PhD Research Fellow A3Lab - DII - Università Politecnica delle Marche, Ancona, Italy skype: leonardo.gabrielli ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AVB not so dead after all
On Sun, Jun 7, 2015 at 10:15 AM, Len Ovens l...@ovenwerks.net wrote: I was listening in on a IRC conversation about the differences between ALSA and Core audio and why Core audio does it right. The difference ends up being this HW clock. That is ALSA is build the way it is because the PC requires it to be. This isn't true. I'm not sure what you're thinking of/referring to. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AVB not so dead after all
Just a few notes, not sure if this is of any use: Motu and Presonus are now shipping some semi-affordable AVB audio devices and switches. The Motu switch is $295. All shipping Apple hardware supports AVB, via the BroadCom NIC they are using. You could of course install Linux on said hardware. Any computer using the same BroadCom chipset can also support AVB. For Windows Echo Audio was making an AVB to ASIO application for this. Again you could install Linux on any of these computers. The NIC that the FreeScale iMX6 and Texas Instruments AM335x (of which the BeagleBone is based) can support AVB. Some audio companies are shipping closed AVB products based on the AM335x and iMX6 that use Linux. I know of one developer who was thinking of making his AVB stack for Linux on AM335x BeagleBone open source but currently it remains a closed solution. Then of course you have the XMOS reference design but that has nothing to do with Linux. I think the cost to do this is becoming a non-issue, with a $200 switch and a BeagleBone based audio interface it should be possible to make a cheap AVB solution on Linux. Just my 2 cents... On Sun, Jun 7, 2015 at 7:15 AM, Len Ovens l...@ovenwerks.net wrote: On Sat, 6 Jun 2015, Reuben Martin wrote: I thought I would post this since there was a big conversation here a while back about AES67 and the slow death of AVB due to lack of support. Well I was talking with a guy from Meyer Sound who told me that AVB has been resurrected from the dead. Apparently Cisco and other large network hardware vendors were willing to back it as long as it was made more generic to accommodate industrial uses that are also time-sensitive. So apparently it has been re-branded as “Time-Sensitive Networking” and has a lot more momentum behind it. http://en.wikipedia.org/wiki/Time-Sensitive_Networking http://www.commercialintegrator.com/article/rebranding_avb_4_key_takeaways_from_time_sensitive_networks_conference Interesting. Some notes on AoIP and Linux. There are some well funded people/companies that use Linux for many things, but much of the development in the audio world is with people who have hardware that they can't afford to replace and so write drivers for. I think this is part of the reason we are not seeing much in the way of Linux drivers for AoIP (AVB, AES67, Ravena, whatever). Right now, AoIP on Linux costs about twice as much as a normal audio card because the Linux box requires both an interface card in the computer as well as the Audio IF on the other end of the network cable (not to mention a switch in the middle). Why is this? Linux is based on lowest common denominator hardware... we call it the PC. The Linux world has gotten much better preformance out of this box than it was designed for. But, in the case of audio, the HW does limit performance at least with AoIP. That limit is the clock. The PC does not have a HW PTP clock built in and in this case software is not good enough. The way around this is with a custom NIC that does. For some reason even though one can buy an ethernet chip that includes a stable PTP clock for less than $5, any NICs I have found with a PTP clock are closer to $1k. I was listening in on a IRC conversation about the differences between ALSA and Core audio and why Core audio does it right. The difference ends up being this HW clock. That is ALSA is build the way it is because the PC requires it to be. Whats the point of all this? TSN sounds good to me. It widens the scope of low latency networking and the requirement of distributed clocking into areas where cost matters. I am hopeful that this means the cost of a NIC with good HW clock will go down or even become standard. All kinds of AoIP would see the benefit from this. I also think the cost of AoIP audio interfaces would come down to similar cost as USB or firewire. There is no reason we could not make an ALSA AES67 driver that would work with any GB-NIC out there but the closed drivers now available show that on a PC latency is double that of Core audio and handles fewer channels. (Core audio at 192K = 64 channels in and out min latency 32 samples, Win at 192k = 16 channels in and out min 64 samples) So any ALSA driver would suffer from similar lower performance. This is why almost all AoIP setups suggest their PCI(e) card in place of your stock NIC. * numbers from: http://www.merging.com/products/networked-audio/for-3rd-party-daw I have seen similar numbers (or worse) elsewhere. * I am not in any way suggesting anyone use 192k sample rate for audio recording or streams. It's use here is only to show the difference in HW capabilities. 48k is what I use and suggest others use. -- Len Ovens www.ovenwerks.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___
Re: [LAD] AVB not so dead after all
Oh and of course you have the Open-AVB project first started by Intel. Looks like folks are talking about getting it running on a BeagleBone or iMX6 based board: http://sourceforge.net/p/open-avb/mailman/message/33026258/ On Sun, Jun 7, 2015 at 12:08 PM, Jesse Cobra jesseco...@gmail.com wrote: Just a few notes, not sure if this is of any use: Motu and Presonus are now shipping some semi-affordable AVB audio devices and switches. The Motu switch is $295. All shipping Apple hardware supports AVB, via the BroadCom NIC they are using. You could of course install Linux on said hardware. Any computer using the same BroadCom chipset can also support AVB. For Windows Echo Audio was making an AVB to ASIO application for this. Again you could install Linux on any of these computers. The NIC that the FreeScale iMX6 and Texas Instruments AM335x (of which the BeagleBone is based) can support AVB. Some audio companies are shipping closed AVB products based on the AM335x and iMX6 that use Linux. I know of one developer who was thinking of making his AVB stack for Linux on AM335x BeagleBone open source but currently it remains a closed solution. Then of course you have the XMOS reference design but that has nothing to do with Linux. I think the cost to do this is becoming a non-issue, with a $200 switch and a BeagleBone based audio interface it should be possible to make a cheap AVB solution on Linux. Just my 2 cents... On Sun, Jun 7, 2015 at 7:15 AM, Len Ovens l...@ovenwerks.net wrote: On Sat, 6 Jun 2015, Reuben Martin wrote: I thought I would post this since there was a big conversation here a while back about AES67 and the slow death of AVB due to lack of support. Well I was talking with a guy from Meyer Sound who told me that AVB has been resurrected from the dead. Apparently Cisco and other large network hardware vendors were willing to back it as long as it was made more generic to accommodate industrial uses that are also time-sensitive. So apparently it has been re-branded as “Time-Sensitive Networking” and has a lot more momentum behind it. http://en.wikipedia.org/wiki/Time-Sensitive_Networking http://www.commercialintegrator.com/article/rebranding_avb_4_key_takeaways_from_time_sensitive_networks_conference Interesting. Some notes on AoIP and Linux. There are some well funded people/companies that use Linux for many things, but much of the development in the audio world is with people who have hardware that they can't afford to replace and so write drivers for. I think this is part of the reason we are not seeing much in the way of Linux drivers for AoIP (AVB, AES67, Ravena, whatever). Right now, AoIP on Linux costs about twice as much as a normal audio card because the Linux box requires both an interface card in the computer as well as the Audio IF on the other end of the network cable (not to mention a switch in the middle). Why is this? Linux is based on lowest common denominator hardware... we call it the PC. The Linux world has gotten much better preformance out of this box than it was designed for. But, in the case of audio, the HW does limit performance at least with AoIP. That limit is the clock. The PC does not have a HW PTP clock built in and in this case software is not good enough. The way around this is with a custom NIC that does. For some reason even though one can buy an ethernet chip that includes a stable PTP clock for less than $5, any NICs I have found with a PTP clock are closer to $1k. I was listening in on a IRC conversation about the differences between ALSA and Core audio and why Core audio does it right. The difference ends up being this HW clock. That is ALSA is build the way it is because the PC requires it to be. Whats the point of all this? TSN sounds good to me. It widens the scope of low latency networking and the requirement of distributed clocking into areas where cost matters. I am hopeful that this means the cost of a NIC with good HW clock will go down or even become standard. All kinds of AoIP would see the benefit from this. I also think the cost of AoIP audio interfaces would come down to similar cost as USB or firewire. There is no reason we could not make an ALSA AES67 driver that would work with any GB-NIC out there but the closed drivers now available show that on a PC latency is double that of Core audio and handles fewer channels. (Core audio at 192K = 64 channels in and out min latency 32 samples, Win at 192k = 16 channels in and out min 64 samples) So any ALSA driver would suffer from similar lower performance. This is why almost all AoIP setups suggest their PCI(e) card in place of your stock NIC. * numbers from: http://www.merging.com/products/networked-audio/for-3rd-party-daw I have seen similar numbers (or worse) elsewhere. * I am not in any way suggesting anyone use 192k sample rate for audio recording or streams. It's use here is only to show the difference
Re: [LAD] AVB not so dead after all
On Sat, 6 Jun 2015, Reuben Martin wrote: I thought I would post this since there was a big conversation here a while back about AES67 and the slow death of AVB due to lack of support. Well I was talking with a guy from Meyer Sound who told me that AVB has been resurrected from the dead. Apparently Cisco and other large network hardware vendors were willing to back it as long as it was made more generic to accommodate industrial uses that are also time-sensitive. So apparently it has been re-branded as “Time-Sensitive Networking” and has a lot more momentum behind it. http://en.wikipedia.org/wiki/Time-Sensitive_Networking http://www.commercialintegrator.com/article/rebranding_avb_4_key_takeaways_from_time_sensitive_networks_conference Interesting. Some notes on AoIP and Linux. There are some well funded people/companies that use Linux for many things, but much of the development in the audio world is with people who have hardware that they can't afford to replace and so write drivers for. I think this is part of the reason we are not seeing much in the way of Linux drivers for AoIP (AVB, AES67, Ravena, whatever). Right now, AoIP on Linux costs about twice as much as a normal audio card because the Linux box requires both an interface card in the computer as well as the Audio IF on the other end of the network cable (not to mention a switch in the middle). Why is this? Linux is based on lowest common denominator hardware... we call it the PC. The Linux world has gotten much better preformance out of this box than it was designed for. But, in the case of audio, the HW does limit performance at least with AoIP. That limit is the clock. The PC does not have a HW PTP clock built in and in this case software is not good enough. The way around this is with a custom NIC that does. For some reason even though one can buy an ethernet chip that includes a stable PTP clock for less than $5, any NICs I have found with a PTP clock are closer to $1k. I was listening in on a IRC conversation about the differences between ALSA and Core audio and why Core audio does it right. The difference ends up being this HW clock. That is ALSA is build the way it is because the PC requires it to be. Whats the point of all this? TSN sounds good to me. It widens the scope of low latency networking and the requirement of distributed clocking into areas where cost matters. I am hopeful that this means the cost of a NIC with good HW clock will go down or even become standard. All kinds of AoIP would see the benefit from this. I also think the cost of AoIP audio interfaces would come down to similar cost as USB or firewire. There is no reason we could not make an ALSA AES67 driver that would work with any GB-NIC out there but the closed drivers now available show that on a PC latency is double that of Core audio and handles fewer channels. (Core audio at 192K = 64 channels in and out min latency 32 samples, Win at 192k = 16 channels in and out min 64 samples) So any ALSA driver would suffer from similar lower performance. This is why almost all AoIP setups suggest their PCI(e) card in place of your stock NIC. * numbers from: http://www.merging.com/products/networked-audio/for-3rd-party-daw I have seen similar numbers (or worse) elsewhere. * I am not in any way suggesting anyone use 192k sample rate for audio recording or streams. It's use here is only to show the difference in HW capabilities. 48k is what I use and suggest others use. -- 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] AVB not so dead after all
I thought I would post this since there was a big conversation here a while back about AES67 and the slow death of AVB due to lack of support. Well I was talking with a guy from Meyer Sound who told me that AVB has been resurrected from the dead. Apparently Cisco and other large network hardware vendors were willing to back it as long as it was made more generic to accommodate industrial uses that are also time-sensitive. So apparently it has been re-branded as “Time-Sensitive Networking” and has a lot more momentum behind it. http://en.wikipedia.org/wiki/Time-Sensitive_Networking http://www.commercialintegrator.com/article/rebranding_avb_4_key_takeaways_from_time_sensitive_networks_conference So make of it what you will. :) I just found it to be interesting. -Reuben ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
