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

[HenrikEnquist]

Originally Posted by Daihedz

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]

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]

Originally Posted by phofman

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]

Originally Posted by emailtim

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:
Screenshot from 2021-03-04 08-59-59.png


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

[emailtim]

Originally Posted by HenrikEnquist

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.