[LAD] FOSS Ethernet Soundcard

[Pieter Palmers]

Karl Hammar wrote:
> Pieter Palmers:
>> Karl Hammar wrote:
> ...
>> But there are plenty of 
>> technical reasons to choose firewire over ethernet (or USB).
> 
> Well, tell us, it will be good to have that documented in a rationale.
> 

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.