I was considering buying the EVO 16 late last year. I saw this "review". What a joke. There is hardly any "there" there. It's a fluff piece, with no real usable information not to mention zero measurements, etc. With a little money you can get some talking heads to say "oh this is a great piece of kit!", and that is basically what I see here.
OTOH, the comparable but with more features MOTU Ultralite mk5 has been well vetted on audiosciencereview.com
I'm personally not looking to save a few quid. I have lots of affordable gear that works well. I am looking for something that would say "this is a set UP". Not sure I get that vibe from the EVO 16 at this time.
OTOH, the comparable but with more features MOTU Ultralite mk5 has been well vetted on audiosciencereview.com
I'm personally not looking to save a few quid. I have lots of affordable gear that works well. I am looking for something that would say "this is a set UP". Not sure I get that vibe from the EVO 16 at this time.
You might, I don't.
But then I remember them when they were still DDA (Dearden Davies Associates) when they were bought by Klark Teknik and merged with Midas.
But then I remember them when they were still DDA (Dearden Davies Associates) when they were bought by Klark Teknik and merged with Midas.
Hi Stephan
I am surprised nobody mentions Topping DM7 which is a 8 channel DAC with extremely high performance and balanced outputs, which you can combine with a PC or Pi, running Camilladsp. I am doing that, and it is working great so far (besides me using very taxing filter currently).
Review here: Topping DM7 Review
I am surprised nobody mentions Topping DM7 which is a 8 channel DAC with extremely high performance and balanced outputs, which you can combine with a PC or Pi, running Camilladsp. I am doing that, and it is working great so far (besides me using very taxing filter currently).
Review here: Topping DM7 Review
thanks all. To be honest I'll wait until Raspberry Pis are available and will try to setup my ideas using CamillaDSP. Most likely using 4 Pis in parallel fed by the same I2S input data stream and giving I2S output data directly to a FDA connected to each Pi. The system should be synchronous because of the common I2S MCLK. I think this will be very versatile for testing. I'll give an update when there is any progress with building the horns itself 🙂
each RPI4 should do filtering for 1 of the 4 ways avoiding the need for multichannel I2S io. Each PI should serve one L+R I2S.
multichannel I2S means very special and expensive hardware in each of the cases as far as I know. Perhaps even a STM32 can be used per channel. I'm considering this at the moment but struggeling implementing the filtering algorithm in python as a test case 🙂
I would not recommend using 4 Pi's. Even if you sync the i2s output to the input (which I'm not sure is possible) there will be a fixed delay going through the pi. Each pi will randomly end up with a slightly different.
Why not use a single pi or anything with a usb port, together with something like this?
https://www.diyinhk.com/shop/audio-...f_out/111-usb_cable-null/141-fifo_option-null
Why not use a single pi or anything with a usb port, together with something like this?
https://www.diyinhk.com/shop/audio-...f_out/111-usb_cable-null/141-fifo_option-null
why should this not be possible? When using analog crossovers large phase shifts are accepted. And in this special case everybody is concerned about the delay difference introduced by the jitter on the MCLK from I2S? According to my understanding: when using a toslink to I2S interface as the master and giving the clock to the PIs and the amplifiers (and of course using equal filter lengths) it should be not a problem. Having small and cheap computer modules is somehow an advantage for me: I can include the computer node + amplifier combination in each horn. Hence every speaker is only supplied with the same optical signal (SPDIF), power and a data link for setting the volume. For me this is a very clean approach.
The delay I was thinking about is the delay from Alsa capture device, through Camilladsp, to the output device. Assuming that input and output devices are synced, then this delay will be constant while camilladsp is running. The problem is that the exact amount of delay will vary from start to start. Camilladsp tries to make it constant by timing the start of capture and playback, but the result will vary by up to a few milliseconds. That's quite a lot for a crossover.
There are also two more potential problems:
- Spdif input hats (and spdif input devices in general really) are poor at handling a stream that is interrupted or changes sample rate. Exactly what happens depends on the device but nearly all misbehave in some way.
- You want to sync the output spdif clock to the input. This means that the device must support using the Spdif input clock as master for the playback side. As far as I know, the common Spdif hats don't support this.
There is a project by @raptorlightning that can help with these two issues. It's very diy in that it requires manufacturing a custom hat.
https://github.com/raptorlightning/I2S-Hat
There are also two more potential problems:
- Spdif input hats (and spdif input devices in general really) are poor at handling a stream that is interrupted or changes sample rate. Exactly what happens depends on the device but nearly all misbehave in some way.
- You want to sync the output spdif clock to the input. This means that the device must support using the Spdif input clock as master for the playback side. As far as I know, the common Spdif hats don't support this.
There is a project by @raptorlightning that can help with these two issues. It's very diy in that it requires manufacturing a custom hat.
https://github.com/raptorlightning/I2S-Hat
Thanks a lot for this information. Regarding Camilla DSP, okay maybe I have had a wrong understanding. My assumption was that when processing time is lower than the time for one chunk of audio data it should work. I have to check this.
As the interface I wanted to start with the generic Wondom / Sure WM8804 TX/RX board. As I understand it the board is able to supply a master clock which can be used by the processing element (maybe Raspberry) and the TX section. One can decide whether the results from filtering go directly to an I2S input amplifier or send via TOSLINK. My hope was that this will work because of the common clock domain of all participants. Don't understand me wrong. I'm happy about the advice. But still interested in building a own solution.
For me the most preferred way is to use a microcontroller per channel with a very defined timing because it has no OS running. Maybe even a 2x 240MHz dual core ESP32 is able to do FFT based filtering in real time. I'll investigate this. It would enable a compact board with processing and amplifier build into a single unit.
Best regards. Stephan
As the interface I wanted to start with the generic Wondom / Sure WM8804 TX/RX board. As I understand it the board is able to supply a master clock which can be used by the processing element (maybe Raspberry) and the TX section. One can decide whether the results from filtering go directly to an I2S input amplifier or send via TOSLINK. My hope was that this will work because of the common clock domain of all participants. Don't understand me wrong. I'm happy about the advice. But still interested in building a own solution.
For me the most preferred way is to use a microcontroller per channel with a very defined timing because it has no OS running. Maybe even a 2x 240MHz dual core ESP32 is able to do FFT based filtering in real time. I'll investigate this. It would enable a compact board with processing and amplifier build into a single unit.
Best regards. Stephan
sorry ony again. Now I understand what you exactly mean. Thanks for this advice. Of course it is not sufficient to have all processing nodes synced by the I2S frame clock. It now became clear to me, that the chunk size (which typically contains many I2S frames) is the elementary processing size and is defined by the FFt size. This must be synced as well.
I'm considering this setup for my next system overhaul. The system would include turntable, CD and BT inputs (maybe a streamer down the road) and the DM7 feeding amplifiers to a 3 or 4 way speaker. My DVD/CD player is an old Sony that has a TOSLINK digital output (no hdmi). In addition to the DM7, I've thought about using the E1DA Cosmos ADC for the turntable. Overkill, yes, but incredible performance for the price and I might want to do measurements down the road. I figure between it and the DM7 I'm probably set for the I/O. My question is how to connect it all to some sort of processor (RPi or mini PC) that will run the DSP. For the RPi, I can use the DIGI+ I/O (or, will I bump into sample rate limitations?). The ADC outputs USB-C and the DM7 input is some sort of USB. For a mini PC - which I'd probably prefer for the greater processing power - I'm not sure how I'd connect the DVD/CD player. Any suggestions for that? Does CamillaDSP provide the ability to configure and select the routing of the inputs to the output, including the I2S? If not, how is that done?
Please tell me if this is hijacking - I'd be happy to start a new thread.
Oh, another thing... I'd love to hear what mini PCs are recommended. Budget, say less than $300.
My topping DM7 arrived today. very well packed (ordered from ShenzhenAudio.
I'm running Archlinux (due to familiarity) On a Dell Optiplex 3050 (x86_64 - Core i3 - 6th gen) mini PC. The downside with this is it has a fan so slight background noise (never seems to ramp up - even during compiles). Also doesn't have built in Wifi (but a cheap Realtek USB Wifi adapter takes care of that)
The mini PC only cost me USD$60 2nd hand, so happy with that. Has both DP++ and separate HDMI port, should I want to do HDMI audio splitting later
The main problem I have is aplay -l doesn't recognise the 8 channels of the DM7 (latest stable kernel - 6.2.6). I believe Ubuntu / Raspbian buster supports the DM7, but will persevere with Archlinux for now.
I am using the DM7 in one of my systems under Ubuntu 22.04 kernel 5.15.xx.. I am able to see/access/use all channels via ALSA.