Go Back   Home > Forums > >

PC Based Computer music servers, crossovers, and equalization

CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc.
CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc.
Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools
Old 2nd March 2021, 10:06 PM   #1691
HenrikEnquist is offline HenrikEnquist  Sweden
diyAudio Member
 
Join Date: Apr 2016
Location: Lund
Quote:
Originally Posted by Daihedz View Post
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.
__________________
CamillaDSP - cross platform dsp engine
Reporting an issue with CamillaDSP? Please attach the config file and the log from a run with "debug" log level.
  Reply With Quote
Old 3rd March 2021, 02:05 AM   #1692
emailtim is offline emailtim  United States
diyAudio Member
 
Join Date: May 2005
Location: USA
Default 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.

Code:
# 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"
}
  Reply With Quote
Old 3rd March 2021, 10:44 AM   #1693
sarcastic1 is online now sarcastic1
diyAudio Member
 
Join Date: Oct 2020
Location: mayday
Quote:
Originally Posted by phofman View Post
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.
  Reply With Quote
Old 3rd March 2021, 03:04 PM   #1694
sarcastic1 is online now sarcastic1
diyAudio Member
 
Join Date: Oct 2020
Location: mayday
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.)


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

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.
  Reply With Quote
Old Yesterday, 09:26 PM   #1695
HenrikEnquist is offline HenrikEnquist  Sweden
diyAudio Member
 
Join Date: Apr 2016
Location: Lund
Quote:
Originally Posted by emailtim View Post
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:
Code:
 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).
__________________
CamillaDSP - cross platform dsp engine
Reporting an issue with CamillaDSP? Please attach the config file and the log from a run with "debug" log level.
  Reply With Quote
Old Yesterday, 09:34 PM   #1696
HenrikEnquist is offline HenrikEnquist  Sweden
diyAudio Member
 
Join Date: Apr 2016
Location: Lund
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.
__________________
CamillaDSP - cross platform dsp engine
Reporting an issue with CamillaDSP? Please attach the config file and the log from a run with "debug" log level.
  Reply With Quote
Old Today, 07:08 PM   #1697
emailtim is offline emailtim  United States
diyAudio Member
 
Join Date: May 2005
Location: USA
Default Possible $samplerate$ switch optimization

Quote:
Originally Posted by HenrikEnquist View Post
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).
Code:
      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).

Code:
/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.

Last edited by emailtim; Today at 07:11 PM.
  Reply to this post

Reply


CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc.Hide this!Advertise here!
Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
The room correction or speaker correction? What can we do with dsp power now availabl Raimonds Full Range 233 28th January 2017 08:51 AM
Introducing OpenDRC, Open Digital Room Correction engine minidsp miniDSP 20 20th January 2016 06:37 PM
What the difference between dsp room correction eq and software correction erez1012 PC Based 0 10th March 2014 08:07 PM
Writing a Cross-Platform, Free Software Modeling Tool and TS-Parameter DB justinzane Software Tools 6 31st December 2013 07:55 AM
FS: DAC, room-correction, active crossovers, amp, speakers! taloyd Swap Meet 4 14th April 2009 04:16 PM


New To Site? Need Help?

All times are GMT. The time now is 08:09 PM.


Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2021 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 15.00%
vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2021 DragonByte Technologies Ltd.
Copyright ©1999-2021 diyAudio
Wiki