CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc.

[phofman]

neither did the (now obvious) incompatibity between linear and log transforms used on REW, compared with those created by just about any audio program I can think of , Avid, Steinberg, Cool, SF, Audacity etc...

What incompatibility do you mean? The sweep frequency increase is either linear of logarithmic. You must know what you are using. Logically a log sweep cannot produce a horizontal line by a linearly-binned FFT. Nicely explained e.g. in Signal Analysis II: Linear vs Logarithmic Sine Sweep .

 

[InspectorGadget]

Nice link phofman.

Square peg, round hole, yes?

 

[TNT]

Professional insight there pohfman!!

//

 

[sarcastic1]

sarcastic1: Why do you use x86 linux?

Many distributions (including debian) have a fixed plan for dumping x86 alltogether. No wonder you cannot find a pre-compiled java 8 for x86 debian 10.

Actually wrong, (on Debian) but nevertheless in that case how come these are the current releases? + There is no 64bit driver for such a sound card.

It's not sure what Digigram intend to do with their LX Dante card either.
(The future belongs to AES67).

A/ Linux raspberrypix86 4.19.0-13-686-pae #1 SMP Debian 4.19.160-2 (2020-11-28) i686 GNU/Linux
NOTE DATE!

B/ Linux raspberrypi 5.10.11-v8+ #1399 SMP PREEMPT Thu Jan 28 12:14:03 GMT 2021 aarch64 GNU/Linux

Nobody told me I can't use the "Buster" distro actually promoted as an "ideal" distro by the Raspi foundation.
Why shouldn't I?

I also have 2 other systems on the same computer.
Ubuntu 18.04LTS (Slow and bloated).
Old 2.6kernel system (which has to be updated via "archive" Linux, fast and not bloated, but buggy).
The same studio sound card works on all 3 btw.

The driver author wrote back today with the issues.

"the onboard ICH6
does NOT have this issue."

Can you think of what may be causing this? (Pmcia card)
Partly the hardware design. The chip has no proper DMA transfer but a
sort of pseudo-DMA that needs the data access via I/O port
read/write.

That costs CPU power.
Win32 might just not take into account the CPU usage in the driver,
who knows.
If you have any improvement in the code, feel free to submit the fix
patch to the upstream.
thanks,
Takashi

'nuff said?

 

[phofman]

Your posts are full of useless noise, utterly unreadable.

Use whatever you want, e.g. raspperrypi linux for x86 32bit, 2.6 kernel or whatever your mix is, just please stop littering this thread.

 

[rolli]

Full Ack

 

[lykkedk]

I just discovered this message that I had completely missed, sorry!
This is very easy to do, I just have to add the beta suffix to the version number. And I agree this would be useful, will do it starting from the next version. I don't plan any more betas of 0.5.0, the next one will be the proper 0.5.0. After that I think Camilladsp is mature enough to make the jump to 1.0.0,

Okay... This is great @Henrik.

Jesper.

 

[xorcz]

s1 I have one spare RPi 3 and I have just tested the REW for you. I took probably the easiest way
1. download and install buster 64 bit Index of /raspios_arm64/images/raspios_arm64-2020-08-24
let it update
2. add repository of adoptopenjdk for buster, see section Raspberry PI OS
Installation | AdoptOpenJDK - Open source, prebuilt OpenJDK binaries

and install the latest JDK 8 hotspot (sudo apt-get install adoptopenjdk-8-hotspot)

3. download and install latest REW beta for Linux from avnirvana REW Linux installer (requires Java 8) | AV NIRVANA
(register first to download)

4. Change sound outpout (raspi-config or manualy) and set it also in the REW.

REW works just fine. RPi is slow for me, but usable.

 

[phofman]

xorcz: but that raspberrypi linux is for x86/i686, not arm32. AdoptJDK 8 for 32bit x86 is not so easy to obtain. No idea why anyone would use such a combination today.

 

[xorcz]

So then build from Azul
Java Download | Java 8, Java 11, Java 13 - Linux, Windows & macOS

It is really difficult to read such long posts.

 

[HenrikEnquist]

Sorry for being so late with this question:

I would like to early intercept every change of $channels$, $format$ and $samplerate$. The purpose would be to trigger some external routines, even before the changes are handled further to camilladsp, this is, before camilladsp starts anew with the updated values.

There is the config_cmd method which could do the job. But maybe there is a more elegant solution.

I think the config_cmd method is the easiest. That's the only easy way I can think of to catch any such change before camilladsp is launched. It's intended to run some command that just builds a config file, but there is nothing stopping you from doing whatever you want.

The only problem I can think of is if your script takes a very long time to run. Then Alsa could complain that it's taking too long to open the device.

 

[emailtim]

PulseAudio Loopback default device using alsa_cdsp

I am trying to get ALSA and PulseAudio to both use the alsa_cdsp automatic rate switcher interface to CamillaDSP.

Could someone recommend a functional configuration to get the PulseAudio Loopback to work with the alsa_cdsp ALSA/asound.conf implementation ?

I have tried various versions, but am not able to get the default audio to launch it via the Loopback. Alsa_cdsp works fine if the app writes to "camilladsp" and PulseAudio Loopback works with the non-alsa_cdsp implementation.

Unfortunately, not all apps allow "camilladsp" to be specified.

If the app writes to the -D "bridge" "type asym" version the alsa_cdsp playback works (same for the "type copy"), but if the app writes to the -D Loopback or default device, the capture from the Loopback does not work.

The Loopback is Card 0 devices 0 and 1 in the list and startup daemon is not running (as per the alsa_cdsp docs) to keep it from conflicting.

Any suggestions would be much appreciated.

# Copy to /etc/asound.conf
pcm.!default {
  type plug
  slave.pcm "bridge"
}

#pcm.bridge {
#  type copy
#  slave.pcm "camilladsp"
#}

pcm.bridge {  # Attempt to read from Loopback and write to camilladsp
  type asym
  capture { pcm "hw:Loopback,1" }
  playback { pcm "camilladsp" }
}

pcm.camilladsp {  # SeaShell's alsa_cdsp automatic output rate switcher
  type cdsp

  cpath "/pathto/camilladsp"
  config_out "/pathto/config_out.yml"
  config_in "/pathto/config_in.yml"
  channels 2

  rates = [
    44100
    48000
    88200
    96000
    176400
    192000
    352800
    384000
  ]

  cargs [
    -p "1234"
    -a "0.0.0.0"
    -l warn
  ]
      
  extra_samples 0
  extra_samples_44100 8192
  extra_samples_48000 8916
}

ctl.!default {
  type hw
  card "Loopback"
}

ctl.bridge {
  type hw
  card "Loopback"
}

 

[sarcastic1]

AdoptJDK 8 for 32bit x86 is not so easy to obtain. No idea why anyone would use such a combination today.

Thank you, perfectly correct and also wrong.

Now for the OS:-

Simply because the 32bit x86 listed as a fully approved download from raspberry pi org, is available as an img file to be written direct to a microSD card.
(Ie. boots from a USB Micro SD reader, as a self contained system,- with "persistence" not off a hard disk).


Why would they do that?
Because they are stupid?

I don't think so, some good reasons:-

Because it enables rapid familiarity with the entire RaspiOS world at high speed on "buster",-

That made it a lot easier to get many programs working on the ARM64 raspi system without the uphill struggle of re-evaluating everything.
You do your homework on a x86 USB card, then pull it out and plug it into the USB slot on the 64 bit Pi.


Some of us don't happen to believe in Intel/X64 anything an more, least of all because my Raspi uses 5W of power, whereas the average notebook uses 60-80W.


There are very many advantages with microSD & swappable media in general which make hard disk systems/USB sound cards look pretty weak.

They can be cloned in minutes, cost peanuts, are easily transferrable between one computer and another, and can transfer the work from ONE OS to another.

Also it so happens a notebook equipped with a studio quality PCMCIA card has direct hi speed bus access to PCI, which nothing else does. (PCMCIA was an excellent standard which the tech boys threw under a bus 'scuse the pun!)

This brings down latency. It means you can swop the card into another machine in seconds.
(Yes now who in their right mind would use a win 32 server OS on a notebook?

me,- because it's much more stable)

I get kinda ratty about people who start criticising & questioning decisions for the sake of it..
That is what appears to be the general drift of all the criticisms of what I am doing and why.

 

[sarcastic1]

OK, we fixed it.
Rew displays the DSP corrections exactly as it should.
The return measurements are edited elsewhere, and a quick run was done.

The whole running "REW on linux" Java8 problems esp with the latest distro "Buster", all turns out to be a waste of time.

Running Camilladsp on ARM64-Linux* works reliably 24/7 without any glitches.
I don't need AMD64 at all.
Arm64 + camilla all start auto as a services, as does VLC, plus the whole test sequence can now be fired up via the web interface of VLC, and uses about 4-5W of power.

Which means it can be left for a day on a car battery without making it impossible to start the engine 24hrs later.
(this makes it possible to run the whole box & make measurements in a car - a sine qua non of the whole op.)

Measurements run fine on win32, and the results now display fine in REW.
QED.

Here are the headphone correction graphs which started all this off.

The corrections on the yml file are visible enough to be able to know what to do with the "Q" factor and resonance Frequency nulling to be able to refine the graphs properly.


NB:- *Arm64 Linux (debian) on Raspberry pi, was considered quite "bleeding edge" until last autumn.

 

[HenrikEnquist]

I am trying to get ALSA and PulseAudio to both use the alsa_cdsp automatic rate switcher interface to CamillaDSP.

Could someone recommend a functional configuration to get the PulseAudio Loopback to work with the alsa_cdsp ALSA/asound.conf implementation ?

I have tried various versions, but am not able to get the default audio to launch it via the Loopback. Alsa_cdsp works fine if the app writes to "camilladsp" and PulseAudio Loopback works with the non-alsa_cdsp implementation.

Unfortunately, not all apps allow "camilladsp" to be specified.

If the app writes to the -D "bridge" "type asym" version the alsa_cdsp playback works (same for the "type copy"), but if the app writes to the -D Loopback or default device, the capture from the Loopback does not work.

The Loopback is Card 0 devices 0 and 1 in the list and startup daemon is not running (as per the alsa_cdsp docs) to keep it from conflicting.

Any suggestions would be much appreciated.

I have tried to use the alsa_cdsp plugin from Pulse just once to check that it works. It was a while ago so I'm not sure I remember it right, but I think I had an Alsa config for the plugin just like in your asound.conf. And then I think added an alsa-sink to PulseAudio with like this:

 pacmd load-module module-alsa-sink device="camilladsp" sink_name="CamillaDSP"
pacmd update-sink-proplist CamillaDSP device.description=CamillaDSP

Then set "camilladsp" as the default device in the control panel for Pulse.
You don't need any loopbacks.


You can add those commands to your pulseaudio config file (without "pacmd" then).

 

[HenrikEnquist]

Final note on REW on linux, then let's drop this topic.
Here is a picture of REW running on Raspberry Pi Desktop (i386) in a virtual machine on my laptop:



I got JRE8 from the link xorcz posted, followed the 2-line instruction for installing it, and then downloaded and installed REW. Done.

 

[emailtim]

Possible $samplerate$ switch optimization

Thanks to @seashell it's now easy to switch config at sample rate changes!
Take a look here: GitHub - scripple/alsa_cdsp: ALSA plugin for Camilla DSP

The alsa_cdsp template specifies the individual sample rates (when using the array specification vs min/max).

      rates = [
        44100 
        48000 
        88200 
        96000
        176400
        192000
        352800
        384000
      ]

The application could add an option to create all sample rate versions of the /pathto/config_out.yml at startup (or add it to a command line tool).

Forex /pathto/config_out_$samplerate$.yml (allow the user to use the $samplerate$ token in destination path and filename).

/pathto/config_out_44100.yml
/pathto/config_out_48000.yml
/pathto/config_out_88200.yml
/pathto/config_out_96000.yml
/pathto/config_out_176400.yml
/pathto/config_out_192000.yml
/pathto/config_out_352800.yml
/pathto/config_out_384000.yml

The app could then just switch filenames between tracks instead of [reading, parsing/substituting and writing] a new config_out.yml on each sample rate change.

 

[HenrikEnquist]

....
The app could then just switch filenames between tracks instead of [reading, parsing/substituting and writing] a new config_out.yml on each sample rate change.

That would be quite a bit faster yes. But the work to read/substitute/write is quite insignificant compared to the restart of camilladsp, so in practice I don't think there would be any noticable speedup

 

[HenrikEnquist]

If someone is wondering about the lack of updates to camilladsp lately, the reason is this:



I'm working on implementing SSE support in RustFFT. The graph shows the speed for power-of-two lengths compared to the standard non-simd implementation (blue curve at 100%) as well as the existing AVX implementation (green curve). The new SSE code is the orange curve.



RustFFT can already use AVX for a major boost, but obviously only on cpus that have AVX. Atoms, Pentiums etc don't. Once this is merged into RustFFT, then systems with these cpus will get a nice boost in convolving and resampling speed.


Later, this will be quite simple to port to Neon. But before that the Neon support in Rust must be improved. At the moment there are too many important instructions missing.

 

[xorcz]

silence threshold and timeout

I just played with silence_timeout
https://www.diyaudio.com/forums/pc-...rossovers-correction-etc-156.html#post6508435
and it depends on the value of samplerate. Timeout is calculated correctly for the 44100Hz.

And one question, which is not related. I paused Audacious, nothing played and later I heard a pop/crack from the speaker. In the log there was:

..
Mar  5 23:09:38 localhost camilladsp[805]: Mar 05 23:09:38.615 DEBG Playback buffer level: 1399.5702127659574, signal rms: [-1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0], module: camillalib::alsadevice
Mar  5 23:09:48 localhost camilladsp[805]: Mar 05 23:09:48.647 DEBG Playback buffer level: 1349.3063829787234, signal rms: [-1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0], module: camillalib::alsadevice
Mar  5 23:09:58 localhost camilladsp[805]: Mar 05 23:09:58.655 DEBG Playback buffer level: 1342.6510638297873, signal rms: [-1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0], module: camillalib::alsadevice
Mar  5 23:10:04 localhost camilladsp[805]: Mar 05 23:10:04.950 WARN Retrying playback, error: ALSA function 'snd_pcm_writei' failed with error 'EPIPE: Broken pipe', module: camillalib::alsadevice
Mar  5 23:10:08 localhost camilladsp[805]: Mar 05 23:10:08.686 DEBG Playback buffer level: 2897.859574468085, signal rms: [-1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0], module: camillalib::alsadevice
Mar  5 23:10:18 localhost camilladsp[805]: Mar 05 23:10:18.717 DEBG Playback buffer level: 5557.565957446808, signal rms: [-1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0, -1000.0], module: camillalib::alsadevice
...

Is it because of CamillaDSP or Audacious?

Config:

devices:
  chunksize: 4096
  capture:
    channels: 2
    device: "hw:Loopback,1"
    format: FLOAT32LE
    type: Alsa
  capture_samplerate: 44100
  enable_rate_adjust: false
  enable_resampling: true
  playback:
    channels: 8
    device: hw:1,10,0
    format: S32LE
    type: Alsa
  resampler_type: BalancedAsync
  samplerate: 96000
filters:
..