Questions and Questions
I finally got a new flash for my 8-channel DAC that works with Linux so I am back at it.
I have a few questions if you don't mind.
Does CamillaDSP use SOX via Rust or does it use another resampling library (crate rubato) ?
Which is more accurate (PulseAudio, SOX, crate rubato or Sabre chip algorithms)?
Would it be more accurate to resample in multiples of 44.1 and 48 separately (not intermix them) ?
The example in the resampling link appears to expect one input/capture rate and one output rate.
Is there a way to accept multiple capture rates and then choose a multiple of 44.1 or 48 as the output rate depending on the current capture rate ?
Example:
[44.1, 88.2, 176.4, 352.8] -> 176.4
[48, 96, 192, 384] -> 192
I can see how this might be doable in the alsa_cdsp rate switcher with some minor mods if it isn't already possible in CamillaDSP.
Thanks much.
Code:
[QUOTE="Daihedz, post: 6212397, member: 390379"]Some benchmarking ...
I set up a pipeline with a "rollercoaster type" SRC parcours from 44.1kHz to 44.1kHz. This pipe is completely useless in terms of audio listening, but not so useless to cumulatively collect possible garbage emerging from it's 6 different stages of SCR:
File Input by Camilladsp | SRC 44.1->192 | 192->48 | 48->176.4 | 176.4->96 | 96->88.2 | 88.2->44.1 | File output by Camilladsp
So a total of eight instances of camilladsp, six of them configured as SRC's. The pipe was run in all different quality presets such as FastSync, FastAsync, BalancedSync, BalancedAsync, AccurateSync and AccurateAsync.
The input signal was a Float64-Bit file, containing six sinewaves, equispaced by one octave along with frequencies such as to produce minimal artefacts while windowing the result @44.1kHz (to avoid swamping the results of the SRC into the artefacts of the windowing itself) The outcoming files were windowed with a Kaiser240 window.
FastSync - All artefacts are <165dB:
[URL="https://www.diyaudio.com/forums/attachments/pc-based/845824d1589992336-camilladsp-cross-platform-iir-fir-engine-crossovers-correction-etc-mt1_fastsync-png"]MT1_FastSync.png[/URL]
FastAsync: - All artefacts are <165dB
[URL="https://www.diyaudio.com/forums/attachments/pc-based/845825d1589992336-camilladsp-cross-platform-iir-fir-engine-crossovers-correction-etc-mt2_fastasync-png"]MT2_FastAsync.png[/URL]
BalancedSync: - All artefacts are <210dB. In terms of artefacts level and artefacts density this one may become my favourite for static SRC's:
[URL="https://www.diyaudio.com/forums/attachments/pc-based/845826d1589992336-camilladsp-cross-platform-iir-fir-engine-crossovers-correction-etc-mt3_balancedsync-png"]MT3_BalancedSync.png[/URL]
BalancedAsync: - All artefacts are <165dB
[URL="https://www.diyaudio.com/forums/attachments/pc-based/845827d1589992336-camilladsp-cross-platform-iir-fir-engine-crossovers-correction-etc-mt4_balancedasync-png"]MT4_BalancedAsync.png[/URL]
AccurateSync: - All artefacts are <230dB
[URL="https://www.diyaudio.com/forums/attachments/pc-based/845828d1589992336-camilladsp-cross-platform-iir-fir-engine-crossovers-correction-etc-mt5_accuratesync-png"]MT5_AccurateSync.png[/URL]
AccurateAsync: - All artefacts are <230dB
[URL="https://www.diyaudio.com/forums/attachments/pc-based/845829d1589992336-camilladsp-cross-platform-iir-fir-engine-crossovers-correction-etc-mt6_accurateasync-png"]MT6_AccurateAsync.png[/URL]
Another difference between Fast, Balanced and Accurate is also the behavior of theirs filters. All filters provide decent attenuations at 22050Hz, thus well avoiding violation of the sampling (Nyquist-Shannon) theorem. Best performer is Accurate, then Balanced, then Fast, "as intended by the inventor" :). The input file contained Float64bit white noise, this time:
[URL="https://www.diyaudio.com/forums/attachments/pc-based/845830d1589992336-camilladsp-cross-platform-iir-fir-engine-crossovers-correction-etc-wn9_camilla_zoom-png"]WN9_Camilla_zoom.png[/URL]
Then -what happens visually to my synthesized "torture impulse"? Despite the demanding, cascaded transformations it remains more or less well shaped - better than I had expected:
[URL="https://www.diyaudio.com/forums/attachments/pc-based/845831d1589992336-camilladsp-cross-platform-iir-fir-engine-crossovers-correction-etc-f9_camilla-png"]F9_Camilla.png[/URL]
And last, not least - I wanted to benchmark against the soxr library. Forget it / no use. Resample-soxr had to vomit riding this roller-coaster. Maybe it's a bug in it's stomach (e.g. within the soxr library) provoking this kind of annoyance:
[URL="https://www.diyaudio.com/forums/attachments/pc-based/845832d1589992336-camilladsp-cross-platform-iir-fir-engine-crossovers-correction-etc-wn9_soxr-png"]WN9_soxr.png[/URL][/QUOTE]I finally got a new flash for my 8-channel DAC that works with Linux so I am back at it.
I have a few questions if you don't mind.
Does CamillaDSP use SOX via Rust or does it use another resampling library (crate rubato) ?
Which is more accurate (PulseAudio, SOX, crate rubato or Sabre chip algorithms)?
Would it be more accurate to resample in multiples of 44.1 and 48 separately (not intermix them) ?
The example in the resampling link appears to expect one input/capture rate and one output rate.
Code:
devices:
samplerate: 96000
...
capture_samplerate: 44100 (*)Is there a way to accept multiple capture rates and then choose a multiple of 44.1 or 48 as the output rate depending on the current capture rate ?
Example:
[44.1, 88.2, 176.4, 352.8] -> 176.4
[48, 96, 192, 384] -> 192
I can see how this might be doable in the alsa_cdsp rate switcher with some minor mods if it isn't already possible in CamillaDSP.
Thanks much.
Last edited:
hi EmailTim,
what 8 channel DAC do you use ... and are you hapy with it ? I'm looking for one to use with Linux
...
OKTO Research DAC8 PRO. I haven't run it through its paces yet in Linux so I am not prepared to comment. I see some others here have one as well.
I am trying to see if it is possible to improve on and bypass the internal Sabre oversampling filter in Linux which may not be possible because the DAC8 has a 192kHz PCM input limit. The PDF indicates bypassing requires at least 8 x (44.1 or 48) PCM to bypass the internal FIR filters.
ES9038Q2M Datasheet
Last edited:
This is possible, but you would need to write for example a python script that listens to the IR receiver and then sends the appropriate commands to the CamillaDSP process.
There isn't any adjustable gain limit on the volume control. But you can work around that. There is a fixed +20 dB gain limit on the volume control. If you add a simple gain filter at for example -15dB, the effective result will be a max gain limit of +5 dB.
You can set the initial volume with a command line parameter when starting the process.
I would not want to make something that works only in some cases, because then it would probably produce garbage if the pipeline is too complicated. To avoid that I would need to do a lot of checking, to make sure the current pipeline is supported by the limited plotter, and give an error message if not. This is probably only a little less work than doing it right from the beginning.
I see how this could be useful in some cases, but loading FRD files is definitely out of the scope for the plotter. My intention is that it should be a tool to show what the DSP is doing, for verifying that a config does what it was intended to do. Not a fancy loudspeaker/room/etc analysis tool.
There is something very strange going on if this doesn't work. You go directly to the S51 device, so nothing in your alsa config files should matter. I don't understand how this can fail
When using CamillaDSP, where should it get it's input from?
The latest config file shows you are capturing from the rockchip i2s input. Do you have a hat with analog in (or spdif in) that you will be using to feed the signal to the DSP? If not, this will not produce any sound.
Or do you want to run the playback software on the Pi? Then either you need to go via a Loopback, or use the alsa-cdsp plugin.
CamillaDSP uses the Rubato library for resampling. I don't know what PulseAudio uses, might be configurable. I guess there is no way of finding out exacly what the Sabre chip does internally, you can only try to guess by measuring the analog output.
SOX does resampling with 32-bit precision, but it's using a library that can also do 64-bit. CamillaDSP by default uses 64-bit. In practice, I don't think there is any audible difference between them.
The accuracy is the same, but doing simple factors like 44.1 -> 88.2 takes a bit less cpu power if you use the synchronous resampler. For the asynchronous there is no such difference.
CamillaDSP can't do this on it's own, but the alsa_cdsp plugin can launch another process (for example a python script) to generate a config file. It would be fairly easy to write with a python script that generates a config with any combination of rates you want.
HenrikEnquist you are correct, i tried today to airplay on the sbc with camilladsp running and was not getting any sound from the sound card
can you help me with what the config input needs to look like and the best way to use the loopback. thanks
link to output from arecord, aplay and my config file
https://www.diyaudio.com/forums/pc-based/349818-camilladsp-cross-platform-iir-fir-engine-crossovers-correction-etc-178.html#post6599856
can you help me with what the config input needs to look like and the best way to use the loopback. thanks
link to output from arecord, aplay and my config file
https://www.diyaudio.com/forums/pc-based/349818-camilladsp-cross-platform-iir-fir-engine-crossovers-correction-etc-178.html#post6599856
Last edited:
I have recently discovered HP T510 thin client. It should be somewhat faster than RPI3 based on some benchmarks. Which minimal linux distro would be good to try out for a network player (basically Spotify streaming only) with 2x4 channel output and CamillaDSP for crossover and delays? I wonder if some global IR correction would be possible on such a low power computer. I can get one like for 1/2 the price of a RPI3.
You will hardly find a more CPU-efficient filter than camilladsp. HP T610 is a bit more powerful.
You may be able to use some 5.1/7.1 PCI-e cards (xonar dx2?) in the PCI-e slots with some extension cables.
Great resource for thin clients is the famous Repurposing Thin Clients
You may be able to use some 5.1/7.1 PCI-e cards (xonar dx2?) in the PCI-e slots with some extension cables.
Great resource for thin clients is the famous Repurposing Thin Clients
I use T620 with a larger M2 drive for 3D printer control (Repetier Server) and T610 with an SSD for CNC router control. I installed the CNC control software on a T510, but yet have to try it out. The 510 is the laziest of them all. I think I just get one more and try it out.
Currently I have Debian on the T510, but I am looking for a small distro to use it without a display, just with an SSH terminal for setup. I am kind of used to Debian/Ubuntu/Mint way od installing things, so I would prefer sone based on that. I was actually considering sone USB 8 output card and I have a cheapo 7.1 card for testing.
Currently I have Debian on the T510, but I am looking for a small distro to use it without a display, just with an SSH terminal for setup. I am kind of used to Debian/Ubuntu/Mint way od installing things, so I would prefer sone based on that. I was actually considering sone USB 8 output card and I have a cheapo 7.1 card for testing.
So it has a VIA Eden X2 U4200 cpu, a dual core x86_64 cpu. It also supports sse4.1, which means it can use the upcoming sse acceleration of the FFT and get a 2x speed increase.
I would guess you can easily run a FIR crossover on it, with several thousand taps per channel at 44.1 kHz.
I can't guess any exact numbers, you'll have to try it to see what it can do.
Sure! First, you need to have an Alsa loopback device like you had here: https://www.diyaudio.com/forums/pc-...rossovers-correction-etc-177.html#post6598792
Then, set up an alsa plug device, as described here: GitHub - HEnquist/camilladsp-config: Help for setting up CamillaDSP, example config files etc
You mention spotify, which means you will be playing 44.1 kHz stuff. Try something like this in the devices section of your config:
Code:
devices:
samplerate: 48000
capture_samplerate: 44100
chunksize: 1024
enable_resampling: true
target_level: 1024
enable_rate_adjust: true
adjust_period: 10
resampler_type: Synchronous
capture:
type: Alsa
channels: 2
device: "hw:Loopback,0,0"
format: S32LE
playback:
type: Alsa
channels: 6
device: "hw:S51"
format: S24LE3New release: 0.5.0-beta5!
Changes since beta 4
New features:
I hope this is the last beta release of 0.5.0.. I have made some changes to the Alsa capture device, which will need a little real world testing.
First change: there is now one more option on the Alsa capture device, "retry_on_error". Normally this should be left at the default of False. But for some quirky devices, setting this to True can make it recover and continue when the signal stops and then comes back. The usb audio gadget mode for example.
Second change is that is now trys to avoid waiting on the blocking IO when reading from an Alsa device. This seems to avoid some driver bugs of some devices, and should not have any impat on others. But there is a risk that is causes trouble, so I would appreciate some feedback from people capturing from Alsa.
Get it from here: Release v0.5.0-beta5 * HEnquist/camilladsp * GitHub
Changes since beta 4
New features:
- Improve validation of filters.
- Setting to enable retry on reads from Alsa capture devices.
- Avoid blocking reads on Alsa capture devices (helps avoiding driver bugs for some devices).
- Fix panic when reloading config if a new filter was defined but not added to the pipeline.
- Check for mixer parameter changes when reloading config.
- Token substutution and overrides also work via websocket.
- Don't exit on SIGHUP when waiting for a config.
- Fix handling of negative values when reading filter coeffs in S24LE3 format.
- Gain filters react to mute setting on reload.
- Fix noise in output when resampling and muting all channels in mixer.
I hope this is the last beta release of 0.5.0.. I have made some changes to the Alsa capture device, which will need a little real world testing.
First change: there is now one more option on the Alsa capture device, "retry_on_error". Normally this should be left at the default of False. But for some quirky devices, setting this to True can make it recover and continue when the signal stops and then comes back. The usb audio gadget mode for example.
Second change is that is now trys to avoid waiting on the blocking IO when reading from an Alsa device. This seems to avoid some driver bugs of some devices, and should not have any impat on others. But there is a risk that is causes trouble, so I would appreciate some feedback from people capturing from Alsa.
Get it from here: Release v0.5.0-beta5 * HEnquist/camilladsp * GitHub