Re: [LAD] FOSS Ethernet Soundcard

Karl Hammar wrote: The most important argument would be that firewire provides the bandwidth, QOS and latency guarantees that ethernet (currently) lacks. Furthermore it also gives access to a global clock which is essential to maintain proper synchronization in a networked environment. Most of these fundamental issues are being addressed by the relevant IEEE 802 spec groups, but those are still in the specification phase, so the hardware you get now will not support this. Note that some hardware available now might be good enough to cut it. But you're going to get 'customers' that expect such a device to work with the onboard laptop ethernet controller (which is first optimized for cost, then optimized for throughput, then maybe for latency). And suppose your laptop happens to have one that doesn't cut it, I wonder how easy it is to find a good ethernet cardbus/expresscard given the fact that all laptops have ethernet on-board for ages now (hence there is virtually no market for add-on ethernet cards). My experience with firewire learns me that even if the specs cover the fundamental issues (as is the case in firewire), the actual chipsets implementing them can (and do) add a load of side-issues to the equation. You need a solid foundation to build on, as chipset vendors cut all corners they can to reduce costs. And *current* ethernet isn't a good foundation for audio. You might want to ask yourself whether you want to go through the hassle of designing an open source soundcard which is only usable in a very controlled environment, i.e. if people have ethernet card X from vendor Y and use switches that use a chipset from vendor Z, being the devices from [insert customers from Z here]. It's a support nightmare. Note that the host-side challenges of using ethernet should not be underestimated. You will have to modify the kernel ethernet driver(s) to discriminate between audio and other packets in a very early stage. Otherwise your audio packets will be deferred to a tasklet and will hence be competing with e.g. video and disk workloads. This issue is currently also present in the 1394 drivers, but the main differences are that there is only one hardware driver for 1394 (as all cards adhere to the OHCI specification) and hence only one place to solve this issue. I don't even want to start counting the number of ethernet drivers in the Linux kernel. A second important difference is that the ethernet subsystem in Linux is used/maintained by people that couldn't care less about audio on Linux, let alone ethernet+audio on Linux. So I think that your chances of getting patches into the kernel that implement things like shifting work from a tasklet to the interrupt handler just for audio might encounter some resistance. </me now really puts his FFADO hat on> Furthermore I think it would be a more directed effort to use a platform like BeBoB or DICE and leverage the work that has already been done, both on the hardware side as on the Linux side (i.e. FFADO). These platforms basically offer everything except for the data-converters and analog stages. Hence the only challenge is designing the (analog) hardware itself. Which IMHO should be a significant one on its own. The added benefit of using an established platform is that it will also work on OSX and windows, meaning that you can reach a larger audience with the hardware and hence have more traction for such a project. Re-writing every kernel ethernet driver to take audio requirements into account and trying to push this into mainline is a waste of time. Maintaining a separate patch-set is a waste of time. Waiting for the specs to settle is a waste of time. A better use of this time would be to improve the FFADO infrastructure (e.g. by implementing a kernel-space streaming driver). This would also benefit the users of the commercial firewire products and would hence help the community as a whole. In the mean time you have a workable solution on the host-side. No offense intended, but the Linux Audio community isn't helped with (yet another) half-baked solution. Note that I don't consider FFADO as fully-baked either. But at least it is already half-baked *at this moment in time*. The challenge is not in starting another project, but in bringing it to a usable level. Unfortunately for open-source the most fun is found in the beginning of a project, where you see a lot of progress. Bringing the project to the usable level however isn't much fun. It means spending several days to find that one rarely occurring bug that makes the system unreliable for long recording sessions or live use. The people that actually enjoy the latter are very rare. So to summarize my opinion: * Low-latency (semi-)pro-audio over ethernet as a concept is not mature and is not a good foundation to build something on that is not a support nightmare. * The ethernet hardware that is abundantly available is probably not usable for audio, even if the 'concept' was mature. * The mainline Linux kernel will not be ready for ethernet audio for a while to come, maybe even due to non-technical reasons. * It is a better use of time to build on and improve what is already there than to re-invent the wheel. Obviously not all things I mention are technical, but as I was typing anyway... Greets, Pieter PS: I didn't want to go into the USB vs FireWire debate, there's plenty of material on that. But I think that even USB is a better idea than ethernet, not because its technically superior but because there is a better ecosystem for audio+usb.