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

Some progress to report, but still not fixed. I noticed something odd about the last error message: not only did the shared object not exist, neither did the directory. Was the directory in the wrong place? I did
Code:
sudo find / -type d -name "alsa-lib"
and discovered it was entirely absent.

After a bit of Googling I decided to
Code:
sudo apt install --reinstall libasound2 libasound2-dev libasound2-data libasound2-plugins

The fourth element turned out to be new, but the first three were re-installed, so now
Code:
/usr/lib/aarch64-linux-gnu/alsa-lib
does exist. Confusingly, so does
Code:
/lib/aarch64-linux-gnu/alsa-lib
although I'm so ignorant this may indeed be the same thing with some sort of redirection/mapping thing. But this doesn't fix it. When I try to
Code:
aplay -D camilla
the error message now reads
Code:
ALSA lib dlmisc.c:339:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_cdsp.so (/lib/aarch64-linux-gnu/alsa-lib/libasound_module_pcm_cdsp.so: cannot open shared object file: No such file or directory)
aplay: main:852: audio open error: No such device or address

Almost identical, but the directory now referenced doesn't include /usr at the start ... So I'm still lost - help! Please
 
johnanon: The alsa_cdsp project builds a custom alsa-lib plugin (shared library libasound_module_pcm_cdsp.so) which your alsa-lib must be able to locate.

Look at the makefile rules alsa_cdsp/Makefile at master * scripple/alsa_cdsp * GitHub

The rule "install" copies the created so file to $(LIBDIR)/alsa-lib/ where the variable LIBDIR is initialized by asking pgk-config to give libdir variable of package alsa

Code:
LIBDIR := $(shell pkg-config --variable=libdir alsa)

On my x86 machine:

Code:
pavel@precision:~$ pkg-config --variable=libdir alsa
/usr/lib/x86_64-linux-gnu

So the plugin libasound_module_pcm_cdsp.so would be searched in /usr/lib/x86_64-linux-gnu/alsa/lib/ . In your case the error message tells the path /lib/aarch64-linux-gnu/alsa-lib/libasound_module_pcm_cdsp.so:

Code:
ALSA lib dlmisc.c:339:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_cdsp.so (/lib/aarch64-linux-gnu/alsa-lib/libasound_module_pcm_cdsp.so: cannot open shared object file: No such file or directory)

Clearly you have not run the 'install' rule alsa_cdsp/Makefile at master * scripple/alsa_cdsp * GitHub when installing your alsa_cdsp. Just note that /lib and /usr directories are writable only by root, therefore the installation must be executed by the root user:

Code:
sudo make install

Of course the command 'make' must be run in the directory where the file with rules Makefile is located, i.e. in the root directory of the git-cloned alsa_cdsp repository.
 
Many thanks @phofman. Now I'm beginning to understand the processes of cloning the github repository and then making sense of what the author, scripple, is telling me what I need to do.

So, I've done that now, and when I type aplay -D camilla I don't get the error message - progress!

But my goal is to stream from Roon via the RoonBridge software already running on my RPi4, and I'm not there yet. So through RoonBridge, Roon sees and reports all the devices that aplay -l lists, and camilla isn't one of them yet. If I type aplay -L I can see camilla listed, so whatever it is, its clearly an entity other than a device. Can you help me configure it to be a device - if that's what I need to do?
 
Check man aplay what the command options do.

aplay -l lists sound cards. aplay -L lists PCM devices. Your camilla device is a PCM device defined in alsa configurations. I do not know if Roon lists both cards and PCM devices, it requires different alsa methods to call. E.g. java does not enumerate PCM devices either which complicates use of e.g. REW (java app) on linux. The easiest solution for the app authors is to offer a text input field or config entry where the user can write the PCM device name as needed, without having to select from some list generated by the application itself.
 
Check man aplay what the command options do.

aplay -l lists sound cards. aplay -L lists PCM devices. Your camilla device is a PCM device defined in alsa configurations. I do not know if Roon lists both cards and PCM devices, it requires different alsa methods to call.

That's also very helpful - thanks. So now I understand from the aplay manual that camilla is a "defined PCM" but what Roon needs to find is a "soundcard/digital device".

E.g. java does not enumerate PCM devices either which complicates use of e.g. REW (java app) on linux. The easiest solution for the app authors is to offer a text input field or config entry where the user can write the PCM device name as needed, without having to select from some list generated by the application itself.

Since I can't rewrite RoonBridge, I need to find a workaround if I'm to get scripple's alsa_cdsp to work in my context, if that's possible. So do I need a virtual soundcard that uses the camilla defined pcm? Is that possible?

Everything I'm reading (and I'm reading load of stuff online about asla and asoundrc/asound.conf) is pretty opaque and rarely actually defines its terms in a way that can be understood without already understanding it all ...

I can see that you can define a PCM to use a specific soundcard as a slave, which sounds related, but the opposite of what I want, isn't it? Don't I want a soundcard (that Roon can see) that uses a specific defined pcm (camilla in my case, which is my defined cdsp type pcm)? But if you understand this stuff, you can see I'm floundering in my ignorance!! What do I need to do to make it work?
 
Last edited:
As I said I have no experience with Roon nor its accessories. Therefore I really cannot confirm Roon lists only cards and not PCM devices, I have not found any relevant discussion online. Is is possible your roonbridge runs under a user which does not have your camilla alsa config in the load path?

If roonbridge really offers/supports cards only, IMO the proper solution is to ask Roon devs to fix such deficiency. IIUC they are pretty capable linux devs, it should be no problem for them.
 
As I said I have no experience with Roon nor its accessories. Therefore I really cannot confirm Roon lists only cards and not PCM devices, I have not found any relevant discussion online.
Thanks for looking. Given what you've already said and what I've reported before, I think we're fairly safe to conclude that Roon only lists soundcards.
Is is possible your roonbridge runs under a user which does not have your camilla alsa config in the load path?
Sounds like a long shot to me. I have no idea how to go about checking that at all. How would I work out the user under which RoonBridge is running? How would I determine what that user's path is? Which is the specific config file you're referring to? The .so file appears in both versions of alsa-lib (if they really are two different versions, not just alternative views of the same directory as I speculated before). Starting from where I am with almost no knowledge, that's pretty daunting, particularly when I'm sceptical it will help.
If roonbridge really offers/supports cards only, IMO the proper solution is to ask Roon devs to fix such deficiency. IIUC they are pretty capable linux devs, it should be no problem for them.
Nice idea, but based on my experience of Roon support and their reluctance to properly respond to, let alone fix two bugs that I know have been well documented, I don't think they will have any appetite for this very niche request.

Do I infer from what you're saying that there is no feasible workaround you're aware of that can be implemented simply? If this is the end of the line, I may just have to give up on alsa-cdsp.
 
Then I have no idea why you would be willing to support them with your money in the first place.
Because Roon does so much right, of course, and what they do for me is well worth what I'm paying. And worth bearing in mind that almost no commercial organisation can possibly service every individual's specific requirements without endangering the viability of the entire enterprise. No doubt the devs are very capable, but they'll have a huge workload too - cut them some slack!
 
Hm, authors of dozens of free-as-beer projects implemented such uncomplicated feature. But as I said I have no idea if Roon really does not offer that. Anyway why don't you raise the question with Roon devs who know their product best? There is no source code available from them, unlike sources of the project here and of countless other ones.
 
Could not resist to buy a 8 chanel I2S out ARM card from RADXA, Rock pi S.
I am totally a linux newbee so a lot of new stuff to learn.

Thanks @LykkeDK, used your GitHub - Lykkedk/SuperPlayer: Hacking software & scripts to play music for learning and starting point.
Disclaimer I have not put any I2S in or out of the card, so maybe it won't work at all.

First babystep is at least accomplised: Configure CamillaDSP 2 in, 6 out and get it to run on the Rock pi S
Enclose the CLI picture of uname and CamillaDSP -v
Hopefully I will get the time and energy to put a SPDIF to I2S and I2S to SPDIF gadget to se if there is actually any signal getting through with the standard DEBIAN configuration of the card.
 

Attachments

  • 2til6kanalradxa.JPG
    2til6kanalradxa.JPG
    319.6 KB · Views: 244
  • null_96000.zip
    490 bytes · Views: 27
Last edited:
Nice. The kernel is hopelessly outdated (an ancient android version), I would be surprised if the I2S worked flawlessly with it (though they may have backported many patches).

The latest kernel I was able to find for rock64 is GitHub - ayufan-rock64/linux-mainline-kernel at release-5.13 . Compared to RPi's 5.15 it's still behind. But maybe they have moved most of the patches to the mainline and no extra patches are required. But very unlikely, even RPi has still custom patches.
 
This is a great project! I have camilladsp and camillagui-backend installed, and a rough loudspeaker crossover built and ready to use!

The computer I'm installing this on is intended to receive signals from an external analogue device. Is it possible to have camilladsp run to monitor the line input?
 
Nice. The kernel is hopelessly outdated (an ancient android version), I would be surprised if the I2S worked flawlessly with it (though they may have backported many patches).
.

Unfortunatly or as expected you were right.
Could not just connect I2S in out and get sound through with channela 0,1 and 0,1,2,3,4,5
See there are 32 channels in/out. See if i can dig up any information of witch channel connects to the spesific physical input/output. (like I2S0_8CH_SDI0 or I2S0_8CH_SDO0)
Think i will need to learn more linux and installing extra software. Could not even start aplay....
Maybe some day I can be able to make or install an overlay.
 
Thank you, unaHm, I will try that.
Maybe a compability chart is needed at some point when more "non linux gurus" want to use camilla dsp on different linux boards than RPI.
See that USB in/out often work, HDMI out often work, but for other formats in/out, it is not that easy to find plattforms that work "out of the box" or with small tested changes.