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

Or you could try the alsa pcm hook with standard squeezelite.

Yeah that is probably the way go thanks. I tried to apply Jespers mods to what I think is the latest squeezelite build 1278 but CamillaDSP throws error 'EINVAL: Invalid argument' when you try to change sample rate.

I had a look at your github. I'll study it some more and have a crack at implementing it. Thanks!
 
As a matter of fact, I did not manage to get either Lykkedk's or my two modified squeezelite variants to work. The code I put together is therefore not guaranteed to work. Please report your progress.

I also believe that seashell's approach is very interesting. But, after a few hours trying, I couldn't make that work either.

Seashell, please explain more about how it is supposed to be configured. As for now, opencmd and closecmd will never fire. I'm just trying to touch files in /tmp, but nothing.

The asound.conf that you have on github, should the content be added to any existing asound.conf, or does it work for you as it is?
 
Maybe getting too off topic here but I successfully built and applied Jespers mods with this version :

GitHub - ralph-irving/squeezelite at 57108946f2117ea0552eab271b81c48fd14387e7

Probably that was the current build at the time.

Nice... :)

I will when i'am getting smarter, do what Henrik suggested some time ago, making a repos. for the squeezelite build... I'am not there yet, sry...

Jesper.
 
SuperPlayer upgrade

Hello all :)

I did a new "howto" GitHub - Lykkedk/SuperPlayer_v2.0

This upgrade guide, uses the p.t. newest builds of the CamillaDSP, Camilla Gui etc... Plotting is not yet enabled as the mathplotlib is very heavy.
I donno if i will make this option work, but the rest is running fine, giving the player a few more seconds for starting up everything is running fine.

I attached a "top" picture of it running on a RPI 3, so i guess running it on a RPI 4 it will be much better?

Jesper.
 

Attachments

  • Top.png
    Top.png
    98 KB · Views: 153
  • Web.png
    Web.png
    66.8 KB · Views: 152

TNT

Member
Joined 2003
Paid Member
Playing a 44,1 ksps track (CD rip) I experience slip (ticks, pops, micro short stutters) while playing say every 10-30 seconds. I use VLC as player but also on other sources.

Also, the first 100 ms of each tracks seem to not play out.

//
 

Attachments

  • sli1.png
    sli1.png
    646.7 KB · Views: 138
  • sli2.png
    sli2.png
    191.9 KB · Views: 144
I'm pretty embarrassed to smear Henrik's CamillaDSP-tread with these of-topic posts. :sorry:
But Jesper (lykkedk) has yet not started his own tread on his GitHub-project. - So where else should we go..? :confused:

I went to cPC to find out what squeezelitle they use.And they use this set of build options:
Code:
Build options: LINUX ALSA EVENTFD RESAMPLE FFMPEG OPUS [COLOR=DarkRed]VISEXPORT[/COLOR] IR GPIO RPI DSD SSL NO_SSLSYM
My guess is that the missing piece in Jesper's build of squeezelite-custom is the option: VISEXPORT.

I have yet not taken the measures to create a build environment for a Rpi.
So I kindly ask Jesper... could you..? (or someone else)
 
Last edited:
Playing a 44,1 ksps track (CD rip) I experience slip (ticks, pops, micro short stutters) while playing say every 10-30 seconds. I use VLC as player but also on other sources.

Also, the first 100 ms of each tracks seem to not play out.

//

If you use an asynchronous USB DAC, you should probably set the "enable_rate_adjust", or else you risk buffer under/over-run due to small differences of the source and DAC clocks.
 
I'm pretty embarrassed to smear Henrik's CamillaDSP-tread with these of-topic posts. :sorry:
But Jesper (lykkedk) has yet not started his own tread on his GitHub-project. - So where else should we go..? :confused:

I went to cPC to find out what squeezelitle they use.And they use this set of build options:
Code:
Build options: LINUX ALSA EVENTFD RESAMPLE FFMPEG OPUS [COLOR=DarkRed]VISEXPORT[/COLOR] IR GPIO RPI DSD SSL NO_SSLSYM
My guess is that the missing piece in Jesper's kompilation of squeezelite-custom is the option: VISEXPORT.

I have yet not taken the measures to create a build environment for a Rpi.
So I kindly ask Jesper... could you..? (or someone else)

Hey... your'e right... also i feel guilty :)
Really i should start a thread myself...

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

I explain how i did it, it's still a dirty hack, but if tuned right it's working pretty good through.
Problem is, that i deleted the "build" machine i used back then, otherwise i could ofcause try to compile it with thoose option's.

I will try to make a new build machine (raspbian), but i do have to go on hollyday's next week, so i won't promise anything fast :rolleyes:

Jesper.
 
It's a synchronous s/pdif (toslink) DAC. Now I run it with rate_adj and chunk size as your suggestion - seem ok.

What does adjust_period do? Will that not be given by itself?

//

Synchronous, asynchronous... It's so confusing.

Asynchronous USB means that the DAC has its own master clock, and "calls" for more data over USB as needed. The source has to adapt, and that is what "enable_rate_adjust" activates. "adjust_period" is how often (seconds) the rate is adjusted to keep the buffer at "target_level".

s/pdif is the opposite. The source has the master clock, and sends data at fixed rate. So "enable_rate_adjust" shouldn't be needed..? :confused:

Here is Henrik's doc on the settings:
GitHub - HEnquist/camilladsp: A flexible linux IIR and FIR engine for crossovers, room correction etc.
 

TNT

Member
Joined 2003
Paid Member
No confusion here :) I use an USB->toslink RME interface so my answer was correct - my DAC is still synchronous but the interfaces that Camilla sees on the computer it is executing on is indeed asynchronous as it is USB :)

My problem seems gone so thats good.

//
 
GUI config status - old status remains... even if new file is loaded I still see this old message..

//
Thanks, yest I have seen this too. It has been working before, not sure how I broke it. It's on my growing todo-list...



Henrik, may I suggest some discrete version info presented in the GUI?

//
Good idea, will do!


Synchronous, asynchronous... It's so confusing.

Asynchronous USB means that the DAC has its own master clock, and "calls" for more data over USB as needed. The source has to adapt, and that is what "enable_rate_adjust" activates. "adjust_period" is how often (seconds) the rate is adjusted to keep the buffer at "target_level".

s/pdif is the opposite. The source has the master clock, and sends data at fixed rate. So "enable_rate_adjust" shouldn't be needed..? :confused:

Here is Henrik's doc on the settings:
GitHub - HEnquist/camilladsp: A flexible linux IIR and FIR engine for crossovers, room correction etc.
The rate adjust actually doesn't have anything to do with sync/async. The problem is that you may have two clock sources, one for the device that CamillaDSP captures audio from, and one for the device it sends it to. It doesn't matter what these devices are (a USB DAC, a virtual soundcard, a dac connected to a soundcard via spdif etc).



A virtual sound card like SoundFlower, och ALSA loopback emulates a sample clock with timers. This wil be close to the exact rate you ask for, but never exactly. The same goes for any physical card.


Let's make a really simple example, say we run on a mac with the SoundFlower virtual sound card as source. We have it running at 48kHz. SoundFlower sets up some timers to generate a 48kHz rate, but the result is always a little off. Lets say it's 47990 Hz.
We are using an asynchronous USB dac. That means the hardware clock of the dac sets the playback rate. This will also be a little off. Let's say 48010 Hz.
Now what happens is that every second, CamillaDSP gets 47990 frames from SoundFlower, while the dac wants 48010. So every second we receive 20 frames less than we send out. If we start with 1000 frames in the buffer, in 50 seconds the buffer will be empty, and we will get an underrun (with a click or pop).



We want to keep the buffer level constant, so we can either

a) Adjust the rate of one of the devices.
or
b) Use resampling to stretch the 47990 samples into 48010.


Both ways get the job done, but a) is the preferred solution. Unfortunately this only works with devices that allow the rate to be adjusted. For now that list contains only the linux Alsa loopback capture device, not SoundFlower on mac or VB cable on windows as these AFAIK don't allow the rate to be adjusted. At some point it will work with the USB Audio Gadget mode too.

b) uses the asynchronous resampler to stretch or compress the audio as needed. This works on all supported systems with all devices.


Both approaches use the setting "adjust_period". This is the time between adjustments and defaults to 10 seconds if it's left out. This means the rate is adjusted approximately once every 10 seconds. The rate difference is measured by monitoring the fill level of the output device buffer.
 
  • Like
Reactions: 1 user