0
$\begingroup$

I'm working on a project bass guitar with individual outputs per string using Nu pickups from Cycfi Research: https://www.cycfi.com/

The common sense approach is to simply take their circular connector and use this to interface, but I'd like to know how realistically could I use a multichannel ADC/MCU to convert the 4 (or more with scalability accounting for 5 strings or two pickups) outputs serially to an RJ45 in real-time? The goal would be to preserve each individual output to process digitally in a box or use a DAC to split the channels back out to process with analog pedals (for example).

This is a question of "could" not "should," and it comes from a place of learning, tinkering, desire to use a more commonly available cable for lower cost (the circular is a good deal for its quality, but it's $84 and not common), and the ability to send power all in one cable. Development time, headache, and cost of electronics inside or outside the guitar are not a factor, this is a hypothetical since I just don't have experience working with multichannel ADCs or ethernet and I'd like to use this as an alternative project to learn from.

I don't mind if this is wrong, I'd just like to understand if this is a rabbit hole or the elusive unobtainium. Thanks in advance!

Improve this question
$\endgroup$
2
  • $\begingroup$ Ethernet is a development nightmare. I would recommend you use multiplexed digital audio over a differential pair, which is your native multi-channel ADC output. That only requires two wires. Depending on the ADC, you also need to transmit a sample clock and a word clock. $\endgroup$
    – Jazzmaniac
    Commented Jan 31, 2021 at 0:18
  • $\begingroup$ Thanks for your response! No worries, I'll look into that. I am also happy using an RJ45 for an application other than ethernet protocol, the goal was to accomplish this with the scalability for 5 to 6 strings which would be 10 to 12 outputs worst case with two pickups. $\endgroup$
    – LinuxGogley
    Commented Jan 31, 2021 at 1:24

2 Answers 2

Reset to default
1
$\begingroup$

I'd just like to understand if this is a rabbit hole or the elusive unobtainium.

A little bit of both. Ethernet is really NOT a great choice for real time audio. You would need a fairly beefy processor that can handle a network stack (TCP or UDP). Getting the latency down to something that's playable is extremely challenging.

Even if you get it on Ethernet, where would it go ? There some multi-channel network formats but these tend to be in the PRO space and expensive.

If you just care about the connector, you can certainly run I2S or TDM through an RJ45 + Ethernet cable. That works quite well (and I've actually managed to incorporate this into a commercial product). Again, you would need some type of receiver that's matched to your transmitter.

Improve this answer
$\endgroup$
5
  • $\begingroup$ Thanks! Yes this is a perfect response, I'm perfectly happy working with a standard serial connection and simply using the RJ45 as an interface. The signal chain is Pickup -> Digital -> box for processing -> Analog for the amp as proof of concept. Ultimately something that processes and amplifies would be awesome, but that's much further down the line. $\endgroup$
    – LinuxGogley
    Commented Jan 31, 2021 at 1:54
  • $\begingroup$ @LinuxGogley but: you want your standard serial to actually work well over some distance, right? Using Fast Ethernet isn't the worst choice there, as it is pretty robust, and a lot of microcontrollers come with the necessary interface to talk to an Ethernet PHY (physical layer adapter chip). The upside (as it's still more complex than doing say, RS485) is that the other end can be any standards-compliant Ethernet device. Especially during development that means you can just use your laptop's network card in a listening-to-everything mode to grab your audio data. $\endgroup$
    – Marcus Müller
    Commented Jan 31, 2021 at 12:01
  • $\begingroup$ Hi Hilmar, as you say, there's actually several professional standards for digital audio over ethernet, and an Ethernet stack isn't that hard to write (it's basically slapping a header onto your payload) if you don't need to handle anything like routing/switching, but just send out ethernet frames. Latency certainly becomes an issue in larger networks, but if you keep packets short and don't try to bridge heavily loaded switches, it will all be < 1ms on anything I can imagine that's not unoptimized userland software trying to read from a TCP socket. (I know this works because of USRP2 SDRs) $\endgroup$
    – Marcus Müller
    Commented Jan 31, 2021 at 12:05
  • $\begingroup$ Something something Dante maybe? I’d probably look around and see if anyone’s done a Dante or CobraNet implementation for a reasonably priced dev kit. I’ve even seen commercial products where the RJ45 connectors just carry analog audio. In a pinch using one to send a multiplexed digital audio signal would probably be a pretty attractive option though. Cable length might be a concern? $\endgroup$
    – Dan Szabo
    Commented Jan 31, 2021 at 20:07
  • $\begingroup$ @MarcusMüller thanks for the info, that's what I was curious about since controllers like the STM32 line have a solid utilities, and since I'm working peer-to-peer I thought I might be in the clear. In addition, using ethernet would have the added benefit of PoE injection and interfacing with something like a Jetson Nano for DSP without building a RJ45 breakout to a GPIO for example. $\endgroup$
    – LinuxGogley
    Commented Feb 1, 2021 at 1:46
0
$\begingroup$

Another approach is to use a lower level interface over RJ45, such as LVDS carrying multiple I2S channels sharing clock. So transmit side would be multiple ADCs clocked together putting I2S into an LVDS transmitter. Receive side has LVDS receiver, recovers the LR clock and data signals to pass to an audio processor.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.