Here are a couple of observations/suggestions: 1. There is a lot more that goes into a product than design (marketing, support, etc.). It may be a good idea to consider partnering with a company that already provides similar services (hardware, support, etc.) because they already have the distribution and marketing set up and operational. It is important not to discount the amount of effort and investment needed to make this happen and to understand that they will need to make some type of investment that has to pay off for them. This can still be done in the open source context, but there has to be some plausible answer to the question "If I put a bunch of money forward for doing the necessary 'missionary work', what is to stop anyone else from coming along and taking advantage of this investment and cutting off my legs with a lower price for the same thing after I've made the investment?". We all realize that an upfront investment in both R&D and marketing is needed for a successful soundcard, because in electronics, the unit costs go down dramatically after you pass each of the 1000, 10,000, and 100,000 unit thresholds. It almost makes the investment in R&D and marketing/sales look like a single cost with one cost for any number of units. Who knows? With an adequate explanation and a plan, one of the existing 'majors' may even provide some funding for this idea. 2. The proposed open hw soundcard is correctly focused on Ethernet. It may turn out that in order to use standard networking gear, that TCPIP be eliminated so you won't be limited by packet size. One way to get this done without having to think about it a lot is to adopt the ATA over Ethernet standard (it's open source) and make the audio read/writes look like a hard disk access. Another potential low cost solution that may dovetail this idea is to use the eSATA ports that a lot of more modern motherboards have built in. If the audio needs to be routed with a router over long distances, this can be attacked separately. It is doubtful if this can be done without some amount of latency. 3. I like the idea of using custom IC hardware. However, I also like using a FPGA (or PLD) to provide the 'glue logic'. One thing that has been learned from the effort of getting an old soundcard driver working (gadget labs - no hardware DMA built in) software DMA support creates a lot of extra effort but reduces the hardware cost. For a network device the equivalent is to use something like RDMA (remote DMA) in Infiniband. Some thought should be given to how to implement in hardware a direct memory to memory transfer without interrupting the CPU on the remote computers. 4. I obviously haven't read or researched enough about this, but some discussion would be warranted on what this will do for the musician that he can't do now. It's probably worth repeating (I'm too thick to get it in just one pass). 5. Obviously, it is important to stick with open source system as much as practical and make sure that the windows drivers are open source which should be part of the license for using the hardware (even if it has to inter-operate with ASIO, WDM, etc.). Best wishes and good luck!! Mike Mazarick _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
