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

Jump to Latest
#2,861
seashell said:
I tried aplay on Debian 11 and it seemed happy. Which player are you using?
Click to expand...
I have been using aplay, my scripts around aplay and JRMC. If I use runlevel 3, I use my own scripts around aplay that use sox and/or ffmpeg and other tools to do the format conversions. If I use runlevel 5 and a GUI, it is JRMC, but I am not married to any of them if something else is more applicable.
seashell said:
Quite a setup. I was hoping you'd found some other gem than the OKTO DAC8 as the world needs more good quality and easily available 8 channel USB DACs.
Click to expand...
Yep, I agree completely. It is always good to have second sources and industry competition is good for customers.

The designer of the well reviewed Khadas Tone Board DAC left the company and started his own company. He indicated they were coming out with a multi-channel DAC that I was anxiously awaiting, but it hasn't materialized, yet. They did come out with 2 of their own balanced DACs after designing the single ended Khadas TBD.
seashell said:
Inherited code is one of the great things about open source. It lets people modify things to their purposes or build new ones. Shared knowledge helps everyone. bluez_alsa could possibly even benefit from some of the changes I've made if they wanted and if the code bases haven't diverged too much for them to no longer be relevant.

One thing though. Given the heritage and license you should have the bluez_alsa copyright information in your MIT license description.
Click to expand...
It is a great learning tool for me as well as a effective jump-starter. The internet is also a wealth of education. Wish it was around when I first started writing code. My learning curve would have been a lot faster. I learned a lot from your user space driver.

If/when I release the VST3 plugin (pondering additional functionality), I will give credit to all of my newly found relatives, friends and family members.
 
#2,862
@emailtim I didn't see any linking issues in Debian 11 using aplay so I was curious where you saw them. Is it specific to your plugin no mine?

I pushed a small update regarding pause when poll is used. It turns out aplay does have a pause button if you run it with -i so I was able to test.

Henrik the glitch I hear in vlc when unpausing doesn't seem to happen with aplay. vlc does not use poll, aplay does. I do occasionally get a message from camilla that it detected a sample rate change when I resume from pause with aplay though. (All this testing under Debian Buster.)
 
#2,863
Hi,

We have a moode 8 test image configured as below and are looking for a few volunteers that have Motu or similar devices that would like to test USB multichannel output capability that is supposed to be included in kernel 5.15.y. If interested email tim at moodeaudio dot org and I'll provide a link to the test image.

RaspiOS: 11.2
Kernel: 5.15.23-v7+ #1525
Arch: armv7l (32-bit)
CamillaDSP: 0.6.3

-Tim
 
#2,864
seashell said:
@emailtim I didn't see any linking issues in Debian 11 using aplay so I was curious where you saw them. Is it specific to your plugin no mine?
Click to expand...

I stumbled on it long before I knew what a VST3 plugin was.

I found the original post to refresh my memory. JRMC doesn't have (or doesn't publish/expose) the ability to enable detailed debugging logs so I couldn't debug it with JRMC. The other player that did have a problem was SoX's play program, not aplay. It gave the error message sufficient to identify the problem and resolve it. Once fixed for SoX's play program, JRMC worked.

Code: 
The program that gave the unresolved symbol was SoX's "play" program when trying
to use the plugin (user space driver).

The JRMC28 logs did not include any specific details about unresolved symbols.
I found the snd_lib_error unresolved symbol by running another application that
did dump a detailed enough error statement to point in the right direction.
The "fix/linker options" worked for that program and JRMC28 as a bonus.

I grepped the "strings" output on Debian 10 of both the resulting linker options
of the driver's .so which yielded same results of:
 [snd_lib_error@@ALSA_0.9 vs snd_lib_error@@ALSA_0.9].

I grepped the "strings" output on Debian 11 of both the resulting linker options
of the driver's .so which yielded the delta of [snd_lib_error vs snd_lib_err@ALSA_0.9],
 with the latter one addressing the missing symbol.

strings libasound_module_pcm_cdsp.so | grep snd_lib_error

So far it works on both Debian 11's 5.10 default and 5.14 (improved lower latency
USB music driver) backports kernels. Hope it doesn't mean it is regressing to an
earlier version of ALSA.  Version 0.9 appears to be quite old (@ 2003).

Debian 10 alsa-utils is on 1.1.8-2
Debian 11 alsa-utils is on 1.2.4-1
Debian 12 alsa-utils is currently on 1.2.5.1-1
 
#2,865
seashell said:
@emailtim I didn't see any linking issues in Debian 11 using aplay so I was curious where you saw them. Is it specific to your plugin no mine?
Click to expand...
I should really keep better notes, or at least add change comments.

I believe these linker options did the trick.

LDFLAGS += -Wall -shared -Wl,--no-as-needed -lasound -Wl,--as-needed

https://wiki.debian.org/ToolChain/DSOLinking#Unresolved_symbols_in_shared_libraries

For the --as-needed default change, a workaround/fix would be to link with "-Wl,--no-as-needed -lfoo -Wl,--as-needed".

Note that the --as-needed and --no-as-needed are positional parameters and the default behavior should be restored after using this workaround.
 
Last edited:
#2,866
phofman said:
Mostly likely pulseaudio has already taken over the card. PA needs to be told to avoid using the card, either via some PA GUI or CLI, e.g. https://askubuntu.com/a/1226710[/ICODE]
Click to expand...
Thanks... that fixed the error for plughw:2,0. Though there is still no sound and the only output is 'dummy output' and only intput is 'monitor dummy output'
I think my o/s is trying to tell me something.. 🙂
 
#2,868
seashell said:
@emailtim I confirm the problem with sox/play on SID. So I added the flags to the makefile. Hopefully it doesn't break other platforms, but I left the original line commented out if it does. This after figuring out the magic two environment variables needed to make sox use an alsa device.
Click to expand...
Hmmm, I don't remember setting any environment variables for SoX's play program.

FWIW, JRMC v28 is "homed" from a Debian 10 build. The problem didn't happen until I built a Debian 11 machine.
 
#2,869
Hi,

Still having intermittent issues with camilladsp RC1/RC2 on raspberrypi bullseye 64 bit. Devices are alsa loopback for capture and Okto Dac 8 Pro via usb for playback. Both capture and playback at 96k. Audio to loopback is via Roonbridge. Pulse audio has been disabled. The problem only seems to occurs when restarting music after camilladsp is in pause state. I have reverted back to version 0.6.3 for the last week and have not had the error. Error seems to occurs multiple times a day with RC2. I am running a python program to monitor camilladsp state and to stop and restart processing. This sometimes clears the issue but it may take a few resets before it works. A sample of the error log is attached.
 

Attachments

#2,871
seashell said:
Quite a setup. I was hoping you'd found some other gem than the OKTO DAC8 as the world needs more good quality and easily available 8 channel USB DACs.
Click to expand...
I just heard back from Soncoz (new company of the KTB designer) and unfortunately they indicated their multi-channel DAC effort has been shelved. They didn't give any details, but it looks like they have expanded their product line in other areas since I last checked.
 
Last edited:
#2,872
Did you try to use a low latency kernel? Seems to help a lot on my linux mint system.
Click to expand...
Not something I have experience with but worth a try. Thanks
Edit: Of course you should start camilladsp and possibly the player with realtime privileges (use chrt for example).
Click to expand...
Roon bridge is setup with a process priority of 0 and camilladsp with process priority of -11. The roon RAAT server process seems to be set with a process priority of -96 when music is being streamed but cpu usage is very low with htop reporting about 1% cpu. I have setup camilladsp systemd service based on the example provided in Henrik's camilladsp-config github page with:
CPUSchedulingPolicy=fifo
CPUSchedulingPriority=10
Click to expand...

When looking up the process priority I noticed processes for pipewire and pulseaudio although pulse audio is configured with no devices, just the loopback as an alsa sink. I am using the same pulse audio configuration as in the example given in Henrik's camilladsp-config github page. I assume this would not cause any problems.

I have no experience with pipewire, will see if I can disable it.
 
#2,874
emailtim said:
They are all warnings and still compile/function within their own context.

FWIW, I locally changed the log macros to have an #if/#else/#endif where the #else block redefines the macros to NOOPS (removing the code from runtime) and removes the runtime "if (FLAG > n)" checks in the #if section.
Click to expand...
Sorry, I missed this reply due to page breaks.

The reason I don't define the debug that way is so that the debug statements are always seen and checked by the compiler regardless of the debug level set at compilation time. This prevents errors in the debug statements from creeping in then you set debug to a higher level and your code no longer compiles.

There is no extra cost at runtime as the code after macro expansion is "if (constant > constant)". The compiler is smart enough to recognize that "if (1 > 2)" will never be true and will not emit the if statement nor the code inside the conditional block. You can easily confirm this by looking at the assembly output of a simple program that we'll make in test.c.

Code: 
#include <stdio.h>
#define DEBUG 1
#define warn(fmt, ...) \
  do { if(DEBUG > 1){fprintf(stderr,"CDSP Plugin WARN: ");\
    fprintf(stderr,((fmt)), ##__VA_ARGS__);} } while (0)

int main(void) {
	warn("Print me?");
	return 0;
}

Compile to assembly: "gcc -S test.cc" which creates the file test.s. Note we're not even specifying a particular level of optimization. We still get the following.

Code: 
	.file	"test.c"
	.text
	.globl	main
	.type	main, @function
main:
.LFB0:
	.cfi_startproc
	pushq	%rbp
	.cfi_def_cfa_offset 16
	.cfi_offset 6, -16
	movq	%rsp, %rbp
	.cfi_def_cfa_register 6
	movl	$0, %eax
	popq	%rbp
	.cfi_def_cfa 7, 8
	ret
	.cfi_endproc
.LFE0:
	.size	main, .-main
	.ident	"GCC: (Debian 8.3.0-6) 8.3.0"
	.section	.note.GNU-stack,"",@progbits

No conditional and no "Print me?" nor mechanism to print it anywhere. If you're not big on assembly and aren't sure let's modify test.c with the extra #if/#else/#endif.

Code: 
#include <stdio.h>
#define DEBUG 1
#if DEBUG > 1
#define warn(fmt, ...) \
  do { if(DEBUG > 1){fprintf(stderr,"CDSP Plugin WARN: ");\
    fprintf(stderr,((fmt)), ##__VA_ARGS__);} } while (0)
#else
#define warn(fmt, ...)
#endif

int main(void) {
	warn("Print me?");
	return 0;
}

Compile to assembly again and the output is completely unchanged.

Code: 
	.file	"test.c"
	.text
	.globl	main
	.type	main, @function
main:
.LFB0:
	.cfi_startproc
	pushq	%rbp
	.cfi_def_cfa_offset 16
	.cfi_offset 6, -16
	movq	%rsp, %rbp
	.cfi_def_cfa_register 6
	movl	$0, %eax
	popq	%rbp
	.cfi_def_cfa 7, 8
	ret
	.cfi_endproc
.LFE0:
	.size	main, .-main
	.ident	"GCC: (Debian 8.3.0-6) 8.3.0"
	.section	.note.GNU-stack,"",@progbits

But now your code is uglier and if you have an error in your warn statement the compiler won't see it until you set DEBUG high enough for warn to be compiled.
 
#2,876
seashell said:
Sorry, I missed this reply due to page breaks.

The reason I don't define the debug that way is so that the debug statements are always seen and checked by the compiler regardless of the debug level set at compilation time. This prevents errors in the debug statements from creeping in then you set debug to a higher level and your code no longer compiles.

There is no extra cost at runtime as the code after macro expansion is "if (constant > constant)". The compiler is smart enough to recognize that "if (1 > 2)" will never be true and will not emit the if statement nor the code inside the conditional block. You can easily confirm this by looking at the assembly output of a simple program that we'll make in test.c.

Code: 
#include <stdio.h>
#define DEBUG 1
#define warn(fmt, ...) \
  do { if(DEBUG > 1){fprintf(stderr,"CDSP Plugin WARN: ");\
    fprintf(stderr,((fmt)), ##__VA_ARGS__);} } while (0)

int main(void) {
    warn("Print me?");
    return 0;
}

Compile to assembly: "gcc -S test.cc" which creates the file test.s. Note we're not even specifying a particular level of optimization. We still get the following.

Code: 
    .file    "test.c"
    .text
    .globl    main
    .type    main, @function
main:
.LFB0:
    .cfi_startproc
    pushq    %rbp
    .cfi_def_cfa_offset 16
    .cfi_offset 6, -16
    movq    %rsp, %rbp
    .cfi_def_cfa_register 6
    movl    $0, %eax
    popq    %rbp
    .cfi_def_cfa 7, 8
    ret
    .cfi_endproc
.LFE0:
    .size    main, .-main
    .ident    "GCC: (Debian 8.3.0-6) 8.3.0"
    .section    .note.GNU-stack,"",@progbits

No conditional and no "Print me?" nor mechanism to print it anywhere. If you're not big on assembly and aren't sure let's modify test.c with the extra #if/#else/#endif.

Code: 
#include <stdio.h>
#define DEBUG 1
#if DEBUG > 1
#define warn(fmt, ...) \
  do { if(DEBUG > 1){fprintf(stderr,"CDSP Plugin WARN: ");\
    fprintf(stderr,((fmt)), ##__VA_ARGS__);} } while (0)
#else
#define warn(fmt, ...)
#endif

int main(void) {
    warn("Print me?");
    return 0;
}

Compile to assembly again and the output is completely unchanged.

Code: 
    .file    "test.c"
    .text
    .globl    main
    .type    main, @function
main:
.LFB0:
    .cfi_startproc
    pushq    %rbp
    .cfi_def_cfa_offset 16
    .cfi_offset 6, -16
    movq    %rsp, %rbp
    .cfi_def_cfa_register 6
    movl    $0, %eax
    popq    %rbp
    .cfi_def_cfa 7, 8
    ret
    .cfi_endproc
.LFE0:
    .size    main, .-main
    .ident    "GCC: (Debian 8.3.0-6) 8.3.0"
    .section    .note.GNU-stack,"",@progbits

But now your code is uglier and if you have an error in your warn statement the compiler won't see it until you set DEBUG high enough for warn to be compiled.
Click to expand...
Thanks for the update.

I know it is ugly, but it stems from old school habits writing embeddded code where it would put you out of flash and CPU budget.

It works the same way on all compilers/optimizers and thus highly portable (QNX, Microware OS-9, Wind River, PowerTV, Linux, etc.).

Not all compilers/optimizers were as bright. The replication/bloat caused by C++ templates nearly tanked one project due to the lack of coalescing functions in compilers. Also had to selectively compile logging by individual source files to fit. Not much of a size issue on modern PCs.

It has been years since I dumped assembly and counted clock cycles. I would usually dump the C preprocessed output to see what got filtered/expanded. If it isn't in that dump, it is guaranteed not to be in the binary (what ever the optimizer settings are).
 
Last edited:
#2,878
seashell said:
I had to set I think it was AUDIODRIVER=ALSA and AUDIODEV=cdsp or else sox played through pulseaudio on a basically stock version of Debian 11 Live CD migrated to SID.
Click to expand...
That's specific for the play name of sox:

https://github.com/chirlu/sox/blob/dd8b63bdc2966c931b73d5f7a17db336cbec6c21/src/sox.c#L2658https://github.com/chirlu/sox/blob/dd8b63bdc2966c931b73d5f7a17db336cbec6c21/src/sox.c#L2538https://github.com/chirlu/sox/blob/dd8b63bdc2966c931b73d5f7a17db336cbec6c21/src/sox.c#L2495
In the regular sox name the device is easy to pass:

Code: 
sox input.flac -t alsa hw:USB
 
  • Like
Reactions: seashell
#2,880
You must log in or register to reply here.
Top Bottom