Just disengaged the rate adjustment. Plays fine - actually sound better I think.
I seem to have the same amount of blipps and plopps actually - there was on or two tight there..
//
I seem to have the same amount of blipps and plopps actually - there was on or two tight there..
//
The asynchronous resampler does that! Just enable rresampling and rate adjust. You already have suitable values for chunksize and target level.
Seems strange, can you post the settings for this?
Without resampling, the enable_rate_adjust won't be able to do anything. And without rate_adjust the resampler won't do anything useful so you can just as well disable it.
Thank you!
To introduce a time shift into a sum of two filters is like moving on the vertical axis between speaker elements. Small time shifts can have big impact on group delay for a sum of two filters.
And why do we care?:
https://www.aes.org/images/e-lib/thumbnails/1/9/19404_full.png
This was for exact the config I posted above i.e. with rate_adjust. Post #1078 i.e. rate_adjust but no resampling.
//
Do you get anything (an error or warning) in the terminal when it blipps?
If not, try starting with -v to get also debug output.
If not, try starting with -v to get also debug output.
I'll do that again! As previous, I didn't see anything there. I'm thinking it might be some sort of interplay between Camilla and Digiface...
//
//
My buffer level has always showed 0. I never thought to question it. Resampling and rate adjust both off. No dropouts except for a brief stutter at first track start sometimes. I turned on rate adjust and buffer level goes to ~2000. I haven't noticed any difference in SQ either way.
If rate adjust is off the buffer level value isn't updated, that's why you have 0 there.
If you use rate_adjust with an alsa loopback capture device, it can do the adjustment without resampling, by tuning the virtual sample rate of the loopback. This doesn't affect the sound quality in any way.
It you don't have rate adjust active, you have a 50% chance to have glitch-free playback. If the loopback is faster than your playback device, it's usually fine. You get a slowly increasing delay through the system. That would be a problem for lip sync in movies but if you are streaming music you probably won't notice.
But if the loopback runs slower, then the playback device will get a buffer underrun once in a while. Then you get a glitch. How often they happen depend on the rate difference and chunksize. A larger chunksize means there are fewer gitches but each one will last longer.
Hi audiac..!
I implemented your sleek "first approach" for sample rate switching with squeezelite, from the pdf you posted.
Works like a charm..!
- after some minor modification, mainly to get it compatible with the new websocket protocol in CamillaDSP.
Since this is a squeezelite/pCP subject I posted the details in lykkedk's thread:
Windows 10 CamillaDSP, ASUS U7 USB soundcard working
Managed to get a CamillaDSP compiled program to run.
https://github.com/HEnquist/camilladsp/releases/download/v0.3.2/camilladsp-windows-amd64.zip
Some windows tayloring was done in config.yml:
Chose low settings for:
Had to set the output to 8 chanels of the ASUS card even if only 4 are used her
Managed to get a CamillaDSP compiled program to run.
https://github.com/HEnquist/camilladsp/releases/download/v0.3.2/camilladsp-windows-amd64.zip
ASUS U7 USB soundcard configured in 8 channel mode. 2 analog in, 8 analog out
Set General and effects setting as in pictures enclosed
Put CamillaDSP program and config.yml in same directory.
Made a minimum config.yml file from the examples in readme file.(zipped file)
Used run (Kjør) to execute the program
Some windows tayloring was done in config.yml:
capture:
type: Wasapi
device: "Linje (Xonar U7)"
format: FLOAT32LE
playback:
type: Wasapi
channels: 8
device: "Høyttalere (Xonar U7)"
format: FLOAT32LE
Chose low settings for:
chunksize: 128
queuelimit: 1
target_level: 128
Had to set the output to 8 chanels of the ASUS card even if only 4 are used her
Attachments
Nice!
A few comments:
- You have input and output on the same device. This means input and output share the sample clock, so there is no drift. You can disable rate adjust (and resampling)!
- On Windows, rate adjust needs the resampler. Enabling rate adjust without also enabling the asynchronous resampler will do nothing.
- I believe you can run with 4 channels if you set the sound card to a 4-speaker config (Sound control panel, click Configure, should give you the speaker config dialog). Then you should be able to set CamillaDSP also to 4 channels. Could you try that?
A few comments:
- You have input and output on the same device. This means input and output share the sample clock, so there is no drift. You can disable rate adjust (and resampling)!
- On Windows, rate adjust needs the resampler. Enabling rate adjust without also enabling the asynchronous resampler will do nothing.
- I believe you can run with 4 channels if you set the sound card to a 4-speaker config (Sound control panel, click Configure, should give you the speaker config dialog). Then you should be able to set CamillaDSP also to 4 channels. Could you try that?
Thank you for your support, Henrik.
Quad speakers did the trick🙂
Also removed:
Noticed that errors in config.yml just crashed the window when using run. Guess it is a windows problem...
Quad speakers did the trick🙂
Also removed:
Code:
adjust_period: 10
enable_rate_adjust: true
enable_resampling: true
resampler_type: BalancedAsyncNoticed that errors in config.yml just crashed the window when using run. Guess it is a windows problem...
Attachments
In windows lingo, what is the playback device if I want to output the sound to a new intance of CamillaDSP?
Hi there.
@Henrik.
I was just wondering about the rate adjust for clock drifts you brought up in your latest post.
Yesterday I opened a thread about a slightly different subject.
It's not related to the convolution. It's related to the recording and filter generation.
REW is using a timing reference chirp inside their sweep. That timing reference puts REW in the position to run a "rate-adjust" to clean up whatever clock drift.
Could Camilla somehow be used to match/rate-adjust the (an) original sweep and the recording.
Just by using e.g. file-in >> Camilla rate-adjust >> file-out >> DRC-Fir impulse response >> DRC-Fir filter
I would like to avoid REW (since there's no CLI) and run the whole recording and filter generation process scripted from commandline.
THX
@Henrik.
I was just wondering about the rate adjust for clock drifts you brought up in your latest post.
Yesterday I opened a thread about a slightly different subject.
It's not related to the convolution. It's related to the recording and filter generation.
REW is using a timing reference chirp inside their sweep. That timing reference puts REW in the position to run a "rate-adjust" to clean up whatever clock drift.
Could Camilla somehow be used to match/rate-adjust the (an) original sweep and the recording.
Just by using e.g. file-in >> Camilla rate-adjust >> file-out >> DRC-Fir impulse response >> DRC-Fir filter
I would like to avoid REW (since there's no CLI) and run the whole recording and filter generation process scripted from commandline.
THX
Last edited:
That is very nice! I like one clock audio systems🙂
So computer/soundcard clock differences is not an issue?
If so: Is it the USB audio 2.0 frame scheme that takes care of soundcard - computer clock differences?
It anables the user to get status messages in the command prompt🙂
ASYNCHRONOUS USB - audiophilleo
ADAPTIVE USB - audiophilleo
Your Xonar U7 is asynchronous USB - Gentoo Forums :: View topic - SOLVED: ASUS Xonar U7-can't capture with this USB sound card - see the lsusb details