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

Jump to Latest
TNT

TNT

Member
Joined 2003
Paid Member
audiac said:
The values 1.001 and 1.0001 doesn't do it either. In layman's terms it's like something is lost in the stream. The next beat comes earlier than expected. No popping sound. It happens more or less every minute, sometimes several times per minute.
Click to expand...

What is your HW equipment chain incl. and after Camilla if one may ask? Do you happen to run a bigger FIR filter in Camilla?

//
 
A

audiac

Member
Joined 2020
Last edited:
S

seashell

Member
Joined 2020
mpd, at least the current version, puts alsa in non-blocking mode so it should be throttling itself so I don't know why it would be using high cpu. Sadly I'm at a loss for what's going on. There's limited debug output in the plugin if you change DEBUG from 0 to 1 at the top but the likely high frequency events are generally silent or else it's overwhelming so I doubt it would be of any value.

If you're using the loopback I guess you can look into the alsa pcm hook I posted earlier.
 
lykkedk

lykkedk

Member
Joined 2002
pCP setup for seashell's "alsa plugin"

Hello.

I've been working on seashell's setup for the piCorePlayer lately.
Eventhrough i tested it on two Pi's i need someone brave to try it out!

It should work.
NOTE : my .TCZ repo. is on SourceForge, as of writing i'am trying to get it working on Git, but so far with no luck.

Find it here :GitHub - Lykkedk/cdsp-samplerate-control: SuperPlayer CamillaDSP SampleRate Control Setup's

Read the guide an do a one liner :
Code: 
tce-load -wi python3.6 && pcp-load -u [url=https://sourceforge.net/projects/cdsp-samplerate-control/files/10.x/armv7/tcz]cdsp_samplerate_control -  Browse /10.x/armv7/tcz at SourceForge.net[/url] -wi seashell_alsa.tcz

Post #160 :
SuperPlayer... The ugly hacked squeezelite samplerate auto switching machine

Jesper.
 
Last edited:
S

seashell

Member
Joined 2020
There's only one poll descriptor in the cdsp plugin though. So there's no order to get wrong. I tried giving it the poll descriptor of the actual pipe in addition to the event poll descriptor of the plugin but that made mpd use 100% of the cpu and also ramped up squeezelite really high. Since the plugin is actually doing the write to the pipe to camilla I figured the music player shouldn't get events from it. Maybe I'm wrong. Anyone more familiar with how ALSA uses poll is welcome to fix the plugin.
 
HenrikEnquist

HenrikEnquist

Member
Joined 2016
seashell said:
There's only one poll descriptor in the cdsp plugin though. So there's no order to get wrong. I tried giving it the poll descriptor of the actual pipe in addition to the event poll descriptor of the plugin but that made mpd use 100% of the cpu and also ramped up squeezelite really high. Since the plugin is actually doing the write to the pipe to camilla I figured the music player shouldn't get events from it. Maybe I'm wrong. Anyone more familiar with how ALSA uses poll is welcome to fix the plugin.
Click to expand...
Hmm so maybe not the same then. I have no idea about alsa and polling (and I don't use MPD).

The discussion there continues here, but doesn't really reach any conclusions: bluez-alsa and mpd 0.21.x don't play well together; cpu pegged * Issue #174 * Arkq/bluez-alsa * GitHub
 
S

seashell

Member
Joined 2020
So looking through the mpd/bluez-alsa conversation gave me an idea which led me to find there is a race condition in the revents callback where the poll event can be triggered even when the buffer is full. The revent flags are cleared so this is I suppose technically ok but it could be the source of mpd's 100% cpu utilization as it might be returning from its poll operations far too often. I don't know as I can't reproduce the high mpd utilization even on a much more powerful system than an rpi running debian buster.

I also eliminated the fake clock. Setting it fast wasn't acceptable as it will eventually trigger an xrun condition in alsa once data isn't available in the internal alsa buffer. Squeezelite triggers this quite frequently with a fast clock as it doesn't load the buffer before starting playback. Now the plugin instead sleeps for ~1/4 period when it looks for more data and there is none. An xrun event is triggered only if an entire period passes and there is still no data available.

In mpd with its non-blocking alsa driver I see a steady cadence of one buffer fill per event as desired and no more extra events with no buffer space available.

In squeezelite I see a very unsteady cadence that basically fills the buffer, dumps it to the pipe, then sleeps until the buffer refills some. I have not seen any xrun conditions occur though.

The delay function may be even less accurate now than it was, but it's never going to be great.

If anyone wants to try the new version it's on github in the branch "fixrace". This is alsa plugin territory though so this may be nothing more than a game of whack-a-mole.
 
Last edited:
S

seashell

Member
Joined 2020
I pushed the changes to the master branch for the plugin. The way the fake clock and the underrun checking worked unless the system clock happened to exactly match the playback clock of the audio device either an underrun in camilla or in the plugin was certain to happen eventually.

I'm pretty sure this is what audiac was hearing with the accelerated fake clock.
 
K

katariat

Member
Joined 2014
Hi All

after some back and forth i was able to get camilladsp to work on my SBC. Now i wanted to set up the configuration file for the cross overs and filters...this is where i need some help. On git the tutorial - step by step example of a 2 by 4 channel crossover ...it starts with "Here let's assume we already figured out all the Loopbacks etc and already know the devices to use"...can some one share their configuration file(s) for reference or share the steps that i can follow

I will be using a creative 5.1 sound card to do my cross over's and filters. i am hoping to airplay via spotify to the sbc and use the camilladsp to do the cross over/ filter...and feed the output to the amp (this is for an active 2 way speaker)

when i use the aplay -l , here is what i get

card 0: rockchiprk3328 [rockchip,rk3328], device 0: ff000000.i2s-i2s-hifi i2s-hifi-0 [ff000000.i2s-i2s-hifi i2s-hifi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: rockchiprk3328 [rockchip,rk3328], device 1: ff010000.i2s-rk3328-hifi ff410000.codec-1 [ff010000.i2s-rk3328-hifi ff410000.codec-1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: rockchiprk3328 [rockchip,rk3328], device 2: ff030000.spdif-dit-hifi dit-hifi-2 [ff030000.spdif-dit-hifi dit-hifi-2]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: S51 [SB X-Fi Surround 5.1], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: S51 [SB X-Fi Surround 5.1], device 1: USB Audio [USB Audio #1]
Subdevices: 1/1
Subdevice #0: subdevice #0

the sound card has 6 analog out put channels (5 + 1 lfe)...in the configuration i am guessing you can choose which channels will be for the woofer vs the mid range/ tweeters

thanks for the help
 
S

seashell

Member
Joined 2020
audiac said:
MPD is now running as it should.

It seems like the sound problems I had with squeezelite are gone as well.

Great job indeed. Excellent! :)
Click to expand...
Good to hear. Thanks for testing. I didn't want to ask as I couldn't blame you for being done with the whole mess. Sorry I didn't spot the squeezelite problem earlier. I didn't realize how far up the ALSA chain things were being impacted.

It's kind of funny in that I've now been hit with a bug with the same function not returning a -1 when it should (during drain) and now with it returning a -1 when it shouldn't, namely the not really an under run lack of data from "clock" mismatch. I've left some debug output active to print to stderr (squeezelite log if enabled) if the plugin actually signals an underrun to ALSA. Hopefully you don't see it.

@TNT if you're asking me I know zero about Mac audio.
 
HenrikEnquist

HenrikEnquist

Member
Joined 2016
TNT said:
All this you are doning for Pi, i.e. a headless player that make use of Camilla (?), I would like to have on Mac. Does this exist?
//
Click to expand...
You mean the automatic rate swithing? And generic for any application (not only squeezelite)? I don't think it can be solved by the software that exists today. SoundFlower and Blackhole are quite similar to the alsa loopback, so they can't tell CamillaDSP when it's time to switch samplerate. And the CPAL library that I'm using doesn't allow changing the configured samplerate of a device. That means the playback samplerate has to be set in audio&midi settings. I think that could be handled by using CoreAudio directly. Possible but a lot of work.


katariat said:
Hi All

after some back and forth i was able to get camilladsp to work on my SBC. Now i wanted to set up the configuration file for the cross overs and filters...this is where i need some help. On git the tutorial - step by step example of a 2 by 4 channel crossover ...it starts with "Here let's assume we already figured out all the Loopbacks etc and already know the devices to use"...can some one share their configuration file(s) for reference or share the steps that i can follow

I will be using a creative 5.1 sound card to do my cross over's and filters. i am hoping to airplay via spotify to the sbc and use the camilladsp to do the cross over/ filter...and feed the output to the amp (this is for an active 2 way speaker)

when i use the aplay -l , here is what i get

card 0: rockchiprk3328 [rockchip,rk3328], device 0: ff000000.i2s-i2s-hifi i2s-hifi-0 [ff000000.i2s-i2s-hifi i2s-hifi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: rockchiprk3328 [rockchip,rk3328], device 1: ff010000.i2s-rk3328-hifi ff410000.codec-1 [ff010000.i2s-rk3328-hifi ff410000.codec-1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: rockchiprk3328 [rockchip,rk3328], device 2: ff030000.spdif-dit-hifi dit-hifi-2 [ff030000.spdif-dit-hifi dit-hifi-2]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: S51 [SB X-Fi Surround 5.1], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: S51 [SB X-Fi Surround 5.1], device 1: USB Audio [USB Audio #1]
Subdevices: 1/1
Subdevice #0: subdevice #0

the sound card has 6 analog out put channels (5 + 1 lfe)...in the configuration i am guessing you can choose which channels will be for the woofer vs the mid range/ tweeters

thanks for the help
Click to expand...
Try this in the devices config:
Code: 
 --- devices:
  samplerate: 44100
  chunksize: 1024
  capture:
    type: Alsa
    channels: 2
    device: "hw:Loopback,1,0"
    format: S32LE
  playback:
    type: Alsa
    channels: 6
    device: "hw:S51"
    format: S32LE
Then add a mixer:
Code: 
 mixers:
   to4chan:
     channels:
       in: 2
       out: 4
     mapping:
       - dest: 0
         sources:
           - channel: 0
             gain: 0
             inverted: false
       - dest: 1
         sources:
           - channel: 1
             gain: 0
             inverted: false
       - dest: 2
         sources:
           - channel: 0
             gain: 0
             inverted: false
       - dest: 3
         sources:
           - channel: 1
             gain: 0
             inverted: false


The channel order of the card is likely: 0: left, 1: right, 2: left surr, 3: right surr, 4: center, 5: lfe.
You can check that with "speaker-test" from Alsa:
Code: 
speaker-test -D hw:S51 -c6 -r44100
Once CamillaDSP is running, point your applications to hw:Loopback,0,0
 
You must log in or register to reply here.
Top Bottom