I now have a RPi3B+ with Raspbian integrated into my system to see what it can do with FIR filter processing.
Good news...
Concurrently, I have the RPi doing these jobs:
1. serving music from an 8T USB hard disc using it's own Logitech Media Server process
2. converting all stored formats to flac (using SoX with no resampling)
3. Running parallel BruteFIR convolver processes for left and right channels using two 64 bit 16384 tap filter sets. (Convolver frequency adapts to original file sample rate)
4. Sending the filtered stereo signal asynchronously over ethernet out to the BBB/Hermes/Cronus, which renders I2S.
I'm watching an 'htop' representation of each core's activity while playing a 176kHz file.
CPU use is not the least bit stressed:
1. fetching and serving uses just 2-3% CPU from one core
2. flac conversion is peaking at almost 30% but is mostly in the low 20%'s of one CPU core. [This step keeps the PCM format constant running into the convolvers.]
3. Parallel BruteFIR convolutions average about 7% and peak around 10% of CPU
Conclusions:
1. RPi/Hermes/Cronus should easily be able to run a 2-way FIR crossover, and with optimization a 3-way.
2. For stereo digital room correction, left/right filter sets at 32k taps should run at 192kHz, or 16k taps at 384kHz.
3. RPi 3B+ is rather slow as a file server, running at 15-20 Mbps. But plenty fast enough for music...
Cheers,
Frank
Good news...
Concurrently, I have the RPi doing these jobs:
1. serving music from an 8T USB hard disc using it's own Logitech Media Server process
2. converting all stored formats to flac (using SoX with no resampling)
3. Running parallel BruteFIR convolver processes for left and right channels using two 64 bit 16384 tap filter sets. (Convolver frequency adapts to original file sample rate)
4. Sending the filtered stereo signal asynchronously over ethernet out to the BBB/Hermes/Cronus, which renders I2S.
I'm watching an 'htop' representation of each core's activity while playing a 176kHz file.
CPU use is not the least bit stressed:
1. fetching and serving uses just 2-3% CPU from one core
2. flac conversion is peaking at almost 30% but is mostly in the low 20%'s of one CPU core. [This step keeps the PCM format constant running into the convolvers.]
3. Parallel BruteFIR convolutions average about 7% and peak around 10% of CPU
Conclusions:
1. RPi/Hermes/Cronus should easily be able to run a 2-way FIR crossover, and with optimization a 3-way.
2. For stereo digital room correction, left/right filter sets at 32k taps should run at 192kHz, or 16k taps at 384kHz.
3. RPi 3B+ is rather slow as a file server, running at 15-20 Mbps. But plenty fast enough for music...
Cheers,
Frank
Hi Miero! Good question. I wanted to get this system running as quickly as possible so I followed the procedure published here:
Archimago's Musings: HOWTO: Logitech Media Server + BrutefirDRC Plugin in Linux Virtual Machine (VM)
This person found that flac worked, but uncompressed 'raw' PCM didn't work in his system. Clearly, there is always room for refinement and this would be an obvious one. The plugin for LMS that runs the BruteFIR engines is in Perl, with which I have no experience. [It was written some time ago by @soundcheck]
One thing I'm doing differently is formatting the filters as text rather than as impulses. So I will mess with trying to simplify that compression step when I can. For me, first I want to learn much more about manipulating phase (using 'rePhase' by @Pos), since I'm still using my trusted IIR filters in ALSA on the BBB.
Cheers,
Frank
I'm running a 96kHz file and seeing CPU use that's inconsistent with what I saw at 176kHz.
I suspect SoX may have been resampling the 176 to, perhaps, 96kHz.
At 96 kHz, one core runs at 5-7% and the second that was active at 176 is sleeping.
Conclusion is the same: The RPi 3-Hermes is going to allow us to re-imagine our system software.
I suspect SoX may have been resampling the 176 to, perhaps, 96kHz.
At 96 kHz, one core runs at 5-7% and the second that was active at 176 is sleeping.
Conclusion is the same: The RPi 3-Hermes is going to allow us to re-imagine our system software.
Last edited:
Hi,
I am assembling BBB/Hermes/Cronus with i2S-hdmi (something like Teleporter). When I play mp3 file my dac locks (44.1khz) but with no sound. I am using bbb-botic-v4-1gb.img.gz image in the http://bbb.ieero.com/index4.shtml.
what can be wrong?
Thank you in advance.
SM
I am assembling BBB/Hermes/Cronus with i2S-hdmi (something like Teleporter). When I play mp3 file my dac locks (44.1khz) but with no sound. I am using bbb-botic-v4-1gb.img.gz image in the http://bbb.ieero.com/index4.shtml.
what can be wrong?
Thank you in advance.
SM
Thank you for the reply.
No I don't have any jumper on Hermes. Do I need ADC header on Hermes installed? If I install it, what setting should I use?
SM
Last edited:
Same thing happes with Flac. 192k flac also locks fine but with no sound.
Thank you
SM
My problem was solved !!!
I had short circuit in the "data" during soldering. Now it works fine. Sounds fantastic !!
I have learned how each I2S signal should looks like in a scope. Thank you for help.
I had short circuit in the "data" during soldering. Now it works fine. Sounds fantastic !!
I have learned how each I2S signal should looks like in a scope. Thank you for help.
Is there a way to ensure that Cronus is actually reclocking the data, and not simply pass-thru of the Amanero?
I have all the flash bits configured as described here, although even when flashing other settings sound is coming through.
Another bit of info, maybe related is that Cronus is measuring a 60mA for 16/44.1 and 68mA for 24/192
I have all the flash bits configured as described here, although even when flashing other settings sound is coming through.
Another bit of info, maybe related is that Cronus is measuring a 60mA for 16/44.1 and 68mA for 24/192
Thanks for the quick reply Brian.
So what would be the difference when I flash
`CPLD_for_1080` and `Slave_for_1080` ? I know `Slave` should be used... but data works if either is flashed (same goes for toggling the `Slave Mode` config bit)
Hi,
I have been using the following combination for over a year.
Amanero -> Buffalo-III-SE-Pro -> Mercury
Sound is great! Now I want to try pure sync Mode (have programed a ATINY85 chip that is ready).
Done following steps
1. Try with Cronos and DAC in async mode.
Added Amanero -> Cronus/Hermes -> Buffalo-III-SE-Pro -> Mercury
Use
CDLP Firmware Slave_for_1080
CPU Firmware, firmware_1099c
and bits
Upsample in HQplayer to 44.1K/DSD256
Sound is great, clearly better than without Cronos. Thanks Russ and Brian!
2. Try DAC in sync mode with default firmware (before trying pure sync)
- Omit the VDD_XO supply to use an external clock.
- Connect buffalo with (a new) 4 inch U.FL cable to Cronos
- No change in Switch Assignments from step 1. I use
switch1: pin 1 = off, 2-8 = on.
switch2: pin 1-2 = on, 3-8 = off (have tried to enable automute pin1=off also)
When I turn on the DAC I get only "static noice" a little less loud then normal listen level, not depenent on volume pot. E.g noice even if volume pot at zero.
I now put back VDD_XO supply, remove clock U.FL cable, power on DAC again, and it plays fine in async with cronus.
Suggestions where to start troubleshooting?
thanks
Micke
I have been using the following combination for over a year.
Amanero -> Buffalo-III-SE-Pro -> Mercury
Sound is great! Now I want to try pure sync Mode (have programed a ATINY85 chip that is ready).
Done following steps
1. Try with Cronos and DAC in async mode.
Added Amanero -> Cronus/Hermes -> Buffalo-III-SE-Pro -> Mercury
Use
CDLP Firmware Slave_for_1080
CPU Firmware, firmware_1099c
and bits
Upsample in HQplayer to 44.1K/DSD256
Sound is great, clearly better than without Cronos. Thanks Russ and Brian!
2. Try DAC in sync mode with default firmware (before trying pure sync)
- Omit the VDD_XO supply to use an external clock.
- Connect buffalo with (a new) 4 inch U.FL cable to Cronos
- No change in Switch Assignments from step 1. I use
switch1: pin 1 = off, 2-8 = on.
switch2: pin 1-2 = on, 3-8 = off (have tried to enable automute pin1=off also)
When I turn on the DAC I get only "static noice" a little less loud then normal listen level, not depenent on volume pot. E.g noice even if volume pot at zero.
I now put back VDD_XO supply, remove clock U.FL cable, power on DAC again, and it plays fine in async with cronus.
Suggestions where to start troubleshooting?
thanks
Micke
hmmm...
What rate clock are you using for the Cronus? Your #2 approach works fine for me with 45.1584 clock in the Cronus, and DSD 256, with clock from Cronus. It probably woudl not work with a 22.5792 clock though, as I m pretty sure the ESS 9038 needs the faster clock for DSD 256.
What rate clock are you using for the Cronus? Your #2 approach works fine for me with 45.1584 clock in the Cronus, and DSD 256, with clock from Cronus. It probably woudl not work with a 22.5792 clock though, as I m pretty sure the ESS 9038 needs the faster clock for DSD 256.
I did the same test and my results are exactly the same as yours.
I use 45 and 48 clocks on Cronus, so clocks are not the problem. Even using all Cronus multipliers, the result is just the same: only noise...
So i think pure sync firmware is needed for using external MCK on BIIIse pro, isn't it?
No...
You can certainly run the DAC without the pure sync firmware with master clock from the Cronus, that is what I am doing. Is your u.fl masterclock cable really 4", that might be a little long, but fit should still work. Make sure the DPLL is all the way open for testing ("highest").
You can certainly run the DAC without the pure sync firmware with master clock from the Cronus, that is what I am doing. Is your u.fl masterclock cable really 4", that might be a little long, but fit should still work. Make sure the DPLL is all the way open for testing ("highest").
Last edited: