USB is one possible solution, but due to the protocol stack that is needed it would be very complicated to implement compared to other serial interface options. I would suggest SPI as it is very simple to implement.
I would consider taking a uC that supports a high-speed SPI interface like the Microchip PIC32. The SPI operates at up to 20Mbps. Additionally, such a uC also has an A/D converter and a DMA module which would simplify the data transfer both into and out of the uC and ensure the speed you are looking for.
There are definitely other uC products that are lower power, but you need to make sure that:
a) the SPI interface can be operated fast enough for your needs
b) the underlying CPU is powerful enough to transfer this amount of data in/out
Don't forget that uC clock frequency has a large influence on power consumption and, considering the speeds probably needed to support this amount of data flow, you may need to consider using the uCs low-power or sleep modes when not actively transferring data to save energy.
Last point - you should define "low-power" in a question like this. A battery could be a small 1000mAh 1.5V cell, or a 12V lead-acid type.
I am assuming that your planned system is:
Analog signal->ModuleA->SPI->cable->SPI->ModuleB
If not, and ModuleB only supports USB,UART,PCI/E etc. then use the uC on the ModuleB side to convert from SPI to USB thus:
Analog signal->ModuleA(uC)->SPI->cable->SPI->(uC)->USB Device->cable->ModuleB
Clarification in response to Edit 1
I would then make the following concrete recommendation. Start by looking at the PIC32MX250F128D. This has a 13 channel, 10-bit A/D and a USB-OTG module. This would become the "uC" element in your "Data flow:" description.
Microchip also offers a free USB software stack which make USB much easier to use.
The USB module on the PIC32MX250F128D can also be used as a 'host' or as a 'device'. Regardless of what ModuleB actually is, the flexibility should be there to interface with it in one or the other modes.
Current consumption lies typically at around 14.5mA at 40MHz, 3.3V and 25°C giving you around 27.5 hours of 'active' (i.e. running at full speed) run time. Beyond that you'll have to look at fine tuning the application code to make use of the various energy saving features the device has (i.e. idle and sleep modes etc.). Reducing frequency of operation has a linear effect on power consumption; supply voltage has a power of 2 (V^2) effect, so reducing your applications voltage supply to the minimum allowed will contribute greatly to battery life.
Hope this provides more to go on. Best regards, Stuart
This sounds more like a networking issue than an electronics issue and may be better asked at that kind of forum.
My instinct is that your wifi bridge is corrupting the trunked serial stream, this could be a number of things, for example packet size.
The way forward would be to use something like wireshark to see what's happening at a network level.
Good luck with your project, it sounds fun!
Best Answer
Before I get into details, let me say that I have probably designed more professional-audio over Ethernet hardware than anyone else-- both in terms of number of different PCB designs as well as number of PCBs manufactured and shipped to end customers. Odds are very high that you have heard products where I have designed the audio over ethernet circuitry in them. (This is pro-audio only, and does not include VOIP or other non-pro products.)
Let's start with the issues:
Software: The hardware is honestly the easy part. The software is difficult. The closer you want to pro-audio performance the harder it is. Your application doesn't sound like pro-audio, but the software task is still not trivial.
Audio Clocking: Transmitting the audio data from point A to point B is relatively easy. Doing it in a way that the two devices have a synchronized audio clock is difficult. Non-pro applications solve this by doing sample rate conversion or just simple drop/duplicate samples as the audio clocks drift. There are difficulties and side effects of both of these, which increases the software difficulty immensely. Just saving the data to a file on the PC side of things is easy-- using it in a real-time way is hard.
Low-latency: How long it takes the audio to go from the Mic, over the network to the PC, and then used by the PC is called latency. The shorter the latency the harder things are. Just saving audio data to a file is a good example of super-long latency, and is one reason why that is also the easiest thing to do. A latency of <2.5 mS is damn hard to do correctly an robustly. The shorter the latency, the less issues there are with things like audio echo and stuff.
Bandwidth: Sending telephone quality audio with high latency is the easiest. Pro-audio quality with low latency is super hard. Using the mic, MCU, and Ethernet interface that you proposed is going to put you into the telephone quality side of things. There are many cases where raw bits-per-second of the Ethernet interface is not the only problem. Other issues like IRQ rate, packet transmit/receive time (not just overall bandwidth), and sometimes packet timing are super important.
Network Topology: As the audio quality goes up (and latency goes down) your network topology becomes really important. I am talking about the number of Ethernet switches, the type of switches, how they are connected, and the number/type of non-audio ethernet devices also on the network. For you this probably wouldn't be an issue, but you never know.
I think that your proposed solution would work for telephone audio quality with a high latency. You'll probably have to do sample dropping/repeating to deal with non-synchronized audio clocks. And it won't be all that great. You might be quite underwhelmed by the audio. I also think that you'll have a lot of software to write on the PC side of things. That being said, I would not do the project with that.
If I were doing the project, I would look at one of the new-ish ARM Cortex-M3 or M4 devices by TI or Freescale that includes a 100 mbps or gigabit ethernet controllers. Many of these things are less than US$10 each and can run at up to 100 MHz. The amount of RAM and Flash makes the task of writing software much easier.
For amusement, my current Audio Over Ethernet project uses an 800 MHz ARM Cortex-A8 with dual gigabit Ethernet ports and runs a customized version of Linux. The system as a whole (not just this Cortex-A8 device) can handle over 2048 audio channels at 48KHz, 32 bit, with an overall system latency of just 2.5 mS (including ADC, DAC, two times over the network, and lots of processing). Audio devices on the network have their sample clocks sync'd to less than 1 uS, even if there are 8+ switch hops in the middle.