This has been mentioned before, but that's now many pages back and I should probably add this in the readme:Well I got everything working, including the web server. I have to say, that's very cool.
I have a couple of issues/questions, though.
I'm using my 2nd gen Scarlett 18i20 as an input for a turntable and trying to do RIAA correction digitally (because why not)
The issue i'm having is that the coefficients in the MiniDSP excel sheet https://www.minidsp.com/images/fbfiles/files/All_digital_coefs_v1-20101026.zip are giving errors in Camilladsp - that the biquad isn't stable.
Any idea why that might be the case? I swapped the a's and b's around and that seems to work.
It's not supposed to look like that, but wait for the new release of the gui that I hope will be ready very soon.
That looks like you are running mismatched versions of the backend and the pycamilladsp library. What versions do you have installed?
It usually runs stable up to quite high cpu load. Anything interesting in the logs? And is the previous beta better?
I searched this thread and didn't find anything. Will try again.
rad! can't wait
camilladsp CamillaDSP 0.4.2
camillagui VERSION = (0, 6, 0)
pycamilladsp doesn't seem to have a version file. Setup.py says 0.5.0
I installed all of these in the last two days, so they should all be the most recent versions (right?)
Thanks!
This is the solution (also quoted above but ended up a bit invisible):
MiniDSP uses the opposite sign of a1 and a2 compared to pretty much everyone else. To use coefficients meant for a MiniDSP, just flip the sign of a1 and a2.
Try with the latest beta of CamillaDSP 0.5.0! I had planned to release the final 0.5.0 already a while back, but there tends to always be one more thing to fix...
Update:
8 channels of CamillaDSP is working on the OKTO Research DAC8 PRO @ 192kHz.
I am using the rate-switcher to switch between native rates. CamillaDSP does the resampling from native to 192kHz. The XO's and filters are in 192kHz.
DSD to PCM conversion is done in the player as well as partial downsampling because Linux/rate switcher doesn't appear to handle higher sample rates. Loopbacks appear to be limited to 192kHz without rebuilding the ALSA code. The rate switcher appears to have some limitations as well, but don't know if it the rate switcher, Linux or something else yet.
Last edited:
As of samplerates - linux USB-audio driver runs fine at maximum USB2 isochronous packet size (yielding 65Mbps) out of the box - example of 2.6MHz/24b/1ch from USB audio gadget https://www.diyaudio.com/forums/equ...ort-samplerates-sw-analyzers.html#post6074296 . Loopback probably does not have any limit, after recompilation e.g. samplerate 19.2MHz Support for high samplerates in SW analyzers . All limits in the existing code are just artificial The only limit is the HW. Maybe it's time to send a patch to devs for raising the loopback limit.
The only limit is the HW. Maybe it's time to send a patch to devs for raising the loopback limit.... . All limits in the existing code are just artificial
384kHz consumer DACs have been around for years (though there is probably not much content). JRiver Media Center's sample rate configuration window has individual settings for rates ranging from [44.1 - 768]kHz with a catchall setting for rates under and over that range. It appears Linux is lagging with the 192kHz limit.
Last edited:
It takes one trivial change in the source code and your loopback can run at any samplerate you wish, all the way up to many megahertz - just change the number in linux/sound/drivers/aloop.c at master * torvalds/linux * GitHub. No way to do that with the other OSes, apart of the fact that neither windows nor OSX have anything like the aloop device to start with
E.g. linux REW has max samplerate limit 1.5MHz.
E.g. linux REW has max samplerate limit 1.5MHz.
Attachments
Well, it took me a minute to figure out how to do the install - can't git pull, have to pull the tarball, then build, then I was good to go.
the web interface is really cool now, lots more information, more responsive. however ... I'm getting way way more xruns than i was before on 0.4.2.
Any idea why that might be the case? It's a simple enough crossover setup.
debug gives :
Code:
Apr 16 14:01:48.801 WARN Prepare playback after buffer underrun, module: camillalib::alsadevice
Apr 16 14:01:48.985 DEBG parsed command: Ok(GetState), module: camillalib::socketserver
Apr 16 14:01:48.999 DEBG parsed command: Ok(GetCaptureSignalRms), module: camillalib::socketserver
Apr 16 14:01:49.010 DEBG parsed command: Ok(GetPlaybackSignalRms), module: camillalib::socketserver
Apr 16 14:01:49.020 DEBG parsed command: Ok(GetCaptureRate), module: camillalib::socketserver
Apr 16 14:01:49.029 DEBG parsed command: Ok(GetRateAdjust), module: camillalib::socketserver
Apr 16 14:01:49.041 DEBG parsed command: Ok(GetBufferLevel), module: camillalib::socketserver
Apr 16 14:01:49.051 DEBG parsed command: Ok(GetClippedSamples), module: camillalib::socketserver
Apr 16 14:01:49.487 DEBG parsed command: Ok(GetState), module: camillalib::socketserver
Apr 16 14:01:49.495 DEBG parsed command: Ok(GetCaptureSignalRms), module: camillalib::socketserver
Apr 16 14:01:49.504 DEBG parsed command: Ok(GetPlaybackSignalRms), module: camillalib::socketserver
Apr 16 14:01:49.518 DEBG parsed command: Ok(GetCaptureRate), module: camillalib::socketserver
Apr 16 14:01:49.527 DEBG parsed command: Ok(GetRateAdjust), module: camillalib::socketserver
Apr 16 14:01:49.538 DEBG parsed command: Ok(GetBufferLevel), module: camillalib::socketserver
Apr 16 14:01:49.548 DEBG parsed command: Ok(GetClippedSamples), module: camillalib::socketserver
Apr 16 14:01:49.986 DEBG parsed command: Ok(GetState), module: camillalib::socketserver
Apr 16 14:01:50.003 DEBG parsed command: Ok(GetCaptureSignalRms), module: camillalib::socketserver
Apr 16 14:01:50.013 DEBG parsed command: Ok(GetPlaybackSignalRms), module: camillalib::socketserver
Apr 16 14:01:50.023 WARN Capture timed out, will try again, module: camillalib::alsadevice
Apr 16 14:01:50.023 DEBG Card inactive, pausing, module: camillalib::alsadevice
Apr 16 14:01:50.024 WARN Capture timed out, will try again, module: camillalib::alsadevice
Apr 16 14:01:50.024 DEBG Card inactive, pausing, module: camillalib::alsadevice
Apr 16 14:01:50.026 WARN Capture timed out, will try again, module: camillalib::alsadevice
Apr 16 14:01:50.026 DEBG Card inactive, pausing, module: camillalib::alsadevice
Apr 16 14:01:50.027 WARN Capture timed out, will try again, module: camillalib::alsadevice
Apr 16 14:01:50.028 DEBG Card inactive, pausing, module: camillalib::alsadevice
Apr 16 14:01:50.035 DEBG parsed command: Ok(GetCaptureRate), module: camillalib::socketserver
Apr 16 14:01:50.044 DEBG parsed command: Ok(GetRateAdjust), module: camillalib::socketserverThis might be caused by the new code that tries to avoid the blocking read. I may have to add a setting to enable that only when needed.
Could you run again -vv, and post your config and the log please? Doesn't matter if the log gets very long, but probably better to attach it than pasting it in the post.
Well it took a while, but I finally have a solution:
I made a hat for the Raspberry Pi. The hat has a WM8804 and an Arduino. This is based on my own previous work with user nattawa's Whazon design. The entire idea of the hat is just to grab the incoming SPDIF signal and retransmit it. In the meantime, the Arduino picks up the frequency and does some fun software work do deal with the 176.4kHz/192kHz issue that the WM8804, otherwise wonderful, has.
With the frequency known, I can tell the Raspberry PI, through GPIO, what it is and a Python script automatically stops and restarts the camilladsp service with the new filter coefficients and transmit rate.
The miniDSP USBStreamer I'm using behaves properly as a transmitter. "Properly" is defined as not doing anything to the sample rate until software control requests it. That is done through ALSA and it works quite well. The filter header is:
I've loaded and tested oratory1990's filter for the HD650 so far, before homebrewing, and it works flawlessly. With the Raspi 4 I have it connected to, camilladsp is only taking ~6% CPU usage at 44.1kHZ up to ~15% at 192kHz. This is a lot of overhead for more complex/accurate filters!
The entire idea behind this is to avoid the standard DAC-->ADC-->DAC conversion chain of the miniDSP products as well as avoiding the resampling that's done by the SHARC and other IC DSP solutions. Yes, you have to code different filters (if you do free-spec coefficient filters) for all resolutions; however, you can just samba share the folder with the filters and access it over the network to upload new filters. Additionally, you have significantly more processing power available to the DSP filter engine than the little SHARC solutions can muster, it's not even comparable.
Images of the hat:
Imgur: The magic of the Internet
It fits in the HifiBerry case, if anyone is wondering. The only current issue with recreating it is the optical receiver and transmitter. I'm using the Everlight EAPLRBA2 Receiver and EAPLTBA4 transmitter, which don't exist anymore (nor do the TORX originals...) for 192kHz. I ordered extras when I did my Whazon build and am glad I did... the only solution now appears to be what the miniDSP uses - DLR2180 and DLT2180, available from Ali in quantity and wait. These are supposedly pin-compatible to the original TORX, I don't know.
Anyways, I've attached the Gerbers, Schematic, BOM, Arduino code, and RasPI Python script if anyone else wants to pursue this avenue. I can upload the KiCAD project as well if requested. You'll have to set up the Python script to load on boot by yourself, as a systemd service (recommended, but there are plenty of other ways). The Raspi 4 is running the 64-bit Ubuntu server build (thank you so much for providing the camilladsp aarch64 binary) so there's really zero overhead to allow camillaDSP free reign over the CPU.
Extra credits to nattawa for helping me with an (admittedly idiotic) debug issue I was having with the board. The new Gerbers attached fix it as it was just a missing net connection.
Quick edit: The instruction for adding oratory1990's filters to camillaDSP came from CamillaDSP IIR filters : oratory1990 They seem to think something is up with the shelf filter compared to what oratory has in his PDFs. The link in the comments allows biquad creation which is a safe workaround.
I made a hat for the Raspberry Pi. The hat has a WM8804 and an Arduino. This is based on my own previous work with user nattawa's Whazon design. The entire idea of the hat is just to grab the incoming SPDIF signal and retransmit it. In the meantime, the Arduino picks up the frequency and does some fun software work do deal with the 176.4kHz/192kHz issue that the WM8804, otherwise wonderful, has.
With the frequency known, I can tell the Raspberry PI, through GPIO, what it is and a Python script automatically stops and restarts the camilladsp service with the new filter coefficients and transmit rate.
The miniDSP USBStreamer I'm using behaves properly as a transmitter. "Properly" is defined as not doing anything to the sample rate until software control requests it. That is done through ALSA and it works quite well. The filter header is:
Code:
capture:
type: Alsa
channels: 2
device: "iec958:CARD=USBStreamer,DEV=0"
format: S32LE
playback:
type: Alsa
channels: 2
device: "iec958:CARD=USBStreamer,DEV=0"
format: S32LEI've loaded and tested oratory1990's filter for the HD650 so far, before homebrewing, and it works flawlessly. With the Raspi 4 I have it connected to, camilladsp is only taking ~6% CPU usage at 44.1kHZ up to ~15% at 192kHz. This is a lot of overhead for more complex/accurate filters!
The entire idea behind this is to avoid the standard DAC-->ADC-->DAC conversion chain of the miniDSP products as well as avoiding the resampling that's done by the SHARC and other IC DSP solutions. Yes, you have to code different filters (if you do free-spec coefficient filters) for all resolutions; however, you can just samba share the folder with the filters and access it over the network to upload new filters. Additionally, you have significantly more processing power available to the DSP filter engine than the little SHARC solutions can muster, it's not even comparable.
Images of the hat:
Imgur: The magic of the Internet
It fits in the HifiBerry case, if anyone is wondering. The only current issue with recreating it is the optical receiver and transmitter. I'm using the Everlight EAPLRBA2 Receiver and EAPLTBA4 transmitter, which don't exist anymore (nor do the TORX originals...) for 192kHz. I ordered extras when I did my Whazon build and am glad I did... the only solution now appears to be what the miniDSP uses - DLR2180 and DLT2180, available from Ali in quantity and wait. These are supposedly pin-compatible to the original TORX, I don't know.
Anyways, I've attached the Gerbers, Schematic, BOM, Arduino code, and RasPI Python script if anyone else wants to pursue this avenue. I can upload the KiCAD project as well if requested. You'll have to set up the Python script to load on boot by yourself, as a systemd service (recommended, but there are plenty of other ways). The Raspi 4 is running the 64-bit Ubuntu server build (thank you so much for providing the camilladsp aarch64 binary) so there's really zero overhead to allow camillaDSP free reign over the CPU.
Extra credits to nattawa for helping me with an (admittedly idiotic) debug issue I was having with the board. The new Gerbers attached fix it as it was just a missing net connection.
Quick edit: The instruction for adding oratory1990's filters to camillaDSP came from CamillaDSP IIR filters : oratory1990 They seem to think something is up with the shelf filter compared to what oratory has in his PDFs. The link in the comments allows biquad creation which is a safe workaround.
Last edited:
This is really neat! Well done!
Could you consider publishing it on a website/github repo/something where it's easier to find? Soon this post will be several pages back in the thread, where very few will see it.
Nice. What is your pc specs? Could you outline your processing chain, i.e. source to dac? Thanks.
SMathews
SMathews
