Re: open hw soundcard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux