Hi all -- long time lurker, first time poster.
I am looking to design a DAC that will be used for live audio (along with an ADC shortly after). A friend of mine at my local hackerspace wants to do a project that does audio over gigabit ethernet on linux. I've offered to do the hardware side, because I'm interested in learning digital audio design. Maybe I'm a geek or just masochistic, but it seems like you guys have a lot of fun and I want in!
Anyway, I'm looking for some suggestions on what to pick. There are a lot of DACs to pick from, but clearly some are better than others for live audio. I'd think that some kind of low latency DAC is ideal for this application, but many DACs have ~32/fs filters which still seem pretty good if I can sample at 192k. Am I wrong to think that this would be the main concern for live audio applications? Are there other things I should be looking at?
I'm also a little concerned about kernel jitter and sampling at 192k... I think Ubuntu Studio 12 uses a "soft realtime" kernel, which might have a few microseconds of jitter.. this could effectively limit me to 96k sampling, probably doubling my filter latencies. I'm also not really looking for top-of-the-line right now, since this will be my first foray into audio design. I don't expect to be approaching the rated SNR of a 120dB chip any time soon. 🙂
Anyway, thanks for reading. Any advice is appreciated!
I am looking to design a DAC that will be used for live audio (along with an ADC shortly after). A friend of mine at my local hackerspace wants to do a project that does audio over gigabit ethernet on linux. I've offered to do the hardware side, because I'm interested in learning digital audio design. Maybe I'm a geek or just masochistic, but it seems like you guys have a lot of fun and I want in!
Anyway, I'm looking for some suggestions on what to pick. There are a lot of DACs to pick from, but clearly some are better than others for live audio. I'd think that some kind of low latency DAC is ideal for this application, but many DACs have ~32/fs filters which still seem pretty good if I can sample at 192k. Am I wrong to think that this would be the main concern for live audio applications? Are there other things I should be looking at?
I'm also a little concerned about kernel jitter and sampling at 192k... I think Ubuntu Studio 12 uses a "soft realtime" kernel, which might have a few microseconds of jitter.. this could effectively limit me to 96k sampling, probably doubling my filter latencies. I'm also not really looking for top-of-the-line right now, since this will be my first foray into audio design. I don't expect to be approaching the rated SNR of a 120dB chip any time soon. 🙂
Anyway, thanks for reading. Any advice is appreciated!
If there are DACs that are limited to 48k but are suitable for live recording, sure I'd be open to them. Otherwise, I'm not really sure why it matters since I can resample after the fact to whatever I want. Something capable of 192k is more flexible and technologically doesn't seem any more difficult.
To me, it seems a non-issue, but if I'm wrong I'd like to know the reasons!
To me, it seems a non-issue, but if I'm wrong I'd like to know the reasons!
The only concern is the buffering of the data, as latency will be the primary concern in a live setting. 192K requires 4 times the amount of bytes compared to 48K.
You of course need a bit more than just an ADC and a DAC - you need some sort of processor/computer to take the data from the ADC and transmit it over the network, and another one at the receiving end to hand the data to the DAC - something like the Raspberry Pi would probably do the job pretty well. Kernel latency is not an issue, as the processor won't be handling individual bytes, but do transfers in chunks of buffer-fulls.
The plan for now is to use an FPGA with gigabit ethernet to interface the DACs and ADCs. I'm not sure how much data we can buffer before latency becomes a problem. At least 100mbit ethernet only has a 1us frame gap, so the processor might be handling individual bytes.
The frame gap for USB is much higher ~1ms.. so I didn't want to use that as the interface -- fine for non-realtime things, but not for live audio methinks.
The frame gap for USB is much higher ~1ms.. so I didn't want to use that as the interface -- fine for non-realtime things, but not for live audio methinks.
Ok, so what latency requirements do you have? 1 us is pretty extreme, I would have thought tens of milliseconds to be sufficient.
Tens of milliseconds latency is definitely audible. I haven't set any strict latency requirements, but the data has to be captured by the ADC, sent to a computer, processed, sent back from the computer and output on the DAC without the musicians noticing. A rough guess would be the order of a few ms or less.
How many miles away is the computer? If it's in the same building, just use S/PDIF over twisted pair or coax. Something like (OK, exactly like) the Behringer SRC2496 makes a reasonable semi-pro ADC/DAC.
I wouldn't have thought that 1 ms was critical; sound only travels a foot through air in that time.
I wouldn't have thought that 1 ms was critical; sound only travels a foot through air in that time.
To get lowest possible latency you'll need to steer clear of S-D type ADCs and DACs. Pick a successive approximation ADC and use a multibit DAC. TDA1545A can go fast enough and they're cheap. Can't see why you'd need 192k - I'd aim for 96k myself as it makes the design of the ADC's AAF much easier.
Thanks abraxalito. Are SD types high latency because of the interpolation filters? I noticed they can be very high SNR, but some of the filters have group delays as high as 512/fs. 192k might be overkill.. I certainly won't exclude a nice ADC or DAC because of it's sample rate.
dangus, it's not so much the distance as it has to do with the ease of setup. A single CAT5 can handle well over 20 stereo channels on gigabit, so it makes life a lot simpler. It seems more and more live audio is going this way. I'm pretty sure it isn't super difficult either. You can easily find ethernet cores for FPGAs on opencores... that should take care of the hard part. I won't say that 1ms latency is necessary, but somewhere around 10 or 20 it becomes quite noticeable for musicians. If you strike a note on your guitar and you don't hear the sound immediately, it's pretty annoying.
dangus, it's not so much the distance as it has to do with the ease of setup. A single CAT5 can handle well over 20 stereo channels on gigabit, so it makes life a lot simpler. It seems more and more live audio is going this way. I'm pretty sure it isn't super difficult either. You can easily find ethernet cores for FPGAs on opencores... that should take care of the hard part. I won't say that 1ms latency is necessary, but somewhere around 10 or 20 it becomes quite noticeable for musicians. If you strike a note on your guitar and you don't hear the sound immediately, it's pretty annoying.
A raspberry pi might work (albeit poorly) for a single DAC or ADC, but never multiple channels. It does not run a realtime OS, so I question whether the substantial kernel jitter could even sample at regular periods within an audio frequency. The number of pins available for connecting devices is quite low, so for expansion purposes, it's a dead end. I really don't want to run the data through 2 OSes. It might make a decent test platform, but is certainly not a solution for any professional applications.
Its the filters yes, but they're not doing interpolation, rather the opposite - decimation. S-D ADCs begin with a modulator running typically at 64X the eventual output sample rate, the output of this modulator has to be sample rate reduced.
They tend to use fairly long FIR filters which are designd to be linear phase. That constraint increases the latency considerably. It would be possible to have an S-D based ADC with much lower latency if it were designed to be minimum (but non-linear) phase.
Hi all here 🙂
Here is my 2 (Canadian) cents...
Latency: as a musician (guitarist) I can live with 10msec latency in recording situation. My drummer starts to hear it off at about 6ms. So aiming for 1ms is somewhat unrealistic, but 5 msec is a fair goal I think. In live situation it becomes a bit more finicky.
It depends...
We found that if the stage monitoring remains in the analog domain, we are safe. (Latency creates confusion in performance) The house system can have quite a bit of delay and it does not really matter for the musicians! for the audience in small venues, it is a whole different story if the monitoring system gets as loud as the house!
I found that a bit of latency is actually a good thing! We have almost no more feedbacks! But it does not work all the time so we still use the antifeedback features of our DBX DriveRack
I guess you are trying to make a ''digital snake'' (For those not on the production side of music, a snake is a multi cored cable that can carry many audio signals in a simpler to handle cable)
A digital snake is an equivalent where the preamps/ADC are placed on the stage and the various signals encoded in stream sent over ... whatever! We use glass optical fiber, 1G fast ethernet two cans and a string 🙂)
We have tried many thing over the years the most practical chain presently is: analog/digital/ADAT encoding (8ch) /framing (to encode 4 adat streams or more) /protocol/transmission medium. (fiber or Gigabyte ethernet)
At the other end, we go receiver/ decode to 4 ADAT stream/ ADAT (in 8ch chuncks) to DAC and then to the console.
We do the process the other way around for line returns and front of house signals. The stage monitoring is mixed live in the analog domain with a second mixer.
We had mixed results over the time with this: AudioRail Technologies The system works fairly well but is extremely dependant of what feeds it its ADAT signals. The problem is with clock synchronisation. We found a way around this by using a master clock system.
In any system you will conjure, the latency will never be as important as the synchronisation of the word clock. This is the most fragile link!
Since last May we bought three Focusrite RedNet 3 RedNet | Focusrite
Do a search on ''Audinate'' and ''Dante''
I can tell you, this is not trivial! it is very complex in reality to get it working right! We are struggling with this more than 5k$ systems and it is not reliable! And Focusrite has far more clout than you or I in a basement can have! These wer due early 2011 and they were available only about 2 months ago. They must have had a lot of problems. We stick with it because we feel that this the way to go, it will eventually work as advertised, and it will be beautiful!
But I repeat, transmitting over the system a low jitter word-clock and keeping it in PERFECT synch all over the system is a major hurdle!
Sincerely, Luc
Here is my 2 (Canadian) cents...
Latency: as a musician (guitarist) I can live with 10msec latency in recording situation. My drummer starts to hear it off at about 6ms. So aiming for 1ms is somewhat unrealistic, but 5 msec is a fair goal I think. In live situation it becomes a bit more finicky.
It depends...
We found that if the stage monitoring remains in the analog domain, we are safe. (Latency creates confusion in performance) The house system can have quite a bit of delay and it does not really matter for the musicians! for the audience in small venues, it is a whole different story if the monitoring system gets as loud as the house!
I found that a bit of latency is actually a good thing! We have almost no more feedbacks! But it does not work all the time so we still use the antifeedback features of our DBX DriveRack
I guess you are trying to make a ''digital snake'' (For those not on the production side of music, a snake is a multi cored cable that can carry many audio signals in a simpler to handle cable)
A digital snake is an equivalent where the preamps/ADC are placed on the stage and the various signals encoded in stream sent over ... whatever! We use glass optical fiber, 1G fast ethernet two cans and a string 🙂)
We have tried many thing over the years the most practical chain presently is: analog/digital/ADAT encoding (8ch) /framing (to encode 4 adat streams or more) /protocol/transmission medium. (fiber or Gigabyte ethernet)
At the other end, we go receiver/ decode to 4 ADAT stream/ ADAT (in 8ch chuncks) to DAC and then to the console.
We do the process the other way around for line returns and front of house signals. The stage monitoring is mixed live in the analog domain with a second mixer.
We had mixed results over the time with this: AudioRail Technologies The system works fairly well but is extremely dependant of what feeds it its ADAT signals. The problem is with clock synchronisation. We found a way around this by using a master clock system.
In any system you will conjure, the latency will never be as important as the synchronisation of the word clock. This is the most fragile link!
Since last May we bought three Focusrite RedNet 3 RedNet | Focusrite
Do a search on ''Audinate'' and ''Dante''
I can tell you, this is not trivial! it is very complex in reality to get it working right! We are struggling with this more than 5k$ systems and it is not reliable! And Focusrite has far more clout than you or I in a basement can have! These wer due early 2011 and they were available only about 2 months ago. They must have had a lot of problems. We stick with it because we feel that this the way to go, it will eventually work as advertised, and it will be beautiful!
But I repeat, transmitting over the system a low jitter word-clock and keeping it in PERFECT synch all over the system is a major hurdle!
Sincerely, Luc
- Status
- Not open for further replies.