Re: [LAD] FOSS Ethernet Soundcard

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.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Sun Dec 6 20:15:03 2009