Go Back   Home > Forums > >
Home Forums Rules Articles diyAudio Store Blogs Gallery Wiki Register Donations FAQ Calendar Search Today's Posts Mark Forums Read

PC Based Computer music servers, crossovers, and equalization

CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc.
CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc.
Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 15th September 2020, 07:35 AM   #821
wineds is online now wineds  Australia
diyAudio Member
 
Join Date: Apr 2006
Location: Melbourne
I am getting a build error when try to build camilladsp :

Requested 'libpulse >= 13.0' but version of libpulse is 12.2
  Reply With Quote
Old 15th September 2020, 08:12 AM   #822
HenrikEnquist is offline HenrikEnquist  Sweden
diyAudio Member
 
Join Date: Apr 2016
Location: Lund
Quote:
Originally Posted by TNT View Post
Looking into it it seems that Homebrew do require the Apple development environment... or? I was hoping to avoid installing that...

//
I think Anaconda provides binary packages, give that a try!
  Reply With Quote
Old 15th September 2020, 08:15 AM   #823
HenrikEnquist is offline HenrikEnquist  Sweden
diyAudio Member
 
Join Date: Apr 2016
Location: Lund
Quote:
Originally Posted by wineds View Post
I am getting a build error when try to build camilladsp :

Requested 'libpulse >= 13.0' but version of libpulse is 12.2
Do you need Pulseaudio? If yes, you need to update the system to get at least 13.0.
If no, just disable the Pulse backend:
Code:
cargo build --release -no-default-features --features alsa-backend --features socketserver
  Reply With Quote
Old 16th September 2020, 03:45 AM   #824
seashell is offline seashell
diyAudio Member
 
Join Date: Sep 2020
Hello and thank you for making this project.

I'm hoping to get some help using it on a raspberry pi 4. I downloaded the binary from github and set up an alsa loopback configuration. It works, but I get frequent dropouts in audio playback. They last about a second, but I think that is the time my hdmi audio extractor / receiver DAC chain takes to recover from a break in the stream so I'm pretty sure the actual breaks are short.

They always happen when camilladsp is first started, or returns to playing after going to sleep, but they also happen randomly during normal play.

I'm running 32 bit Raspberry Pi OS on a 2 GB pi 4 and using the PI's HDMI audio output. I've tried to set the priority higher with nice -10 and it helped some with the random drops, but not so much with the early drops.

The first drop typically comes with "warn...: preparing playback" (or words to that effect) but the other drops do not print anything to screen with -v. (And it's hard to tell with the scrolling of -vv.)

Here's a simple test configuration that I believe should be doing nothing but a pass through that causes the problem. I've also tried with actual FIR filters from 8192 to 65536 taps and it seems to make no difference to the drop frequency.


Any ideas? Something obviously stupid in my config perhaps?


Code:
devices:
  samplerate: 44100
  chunksize: 2048
  silence_threshold: -60
  silence_timeout: 10.0
  capture:
    type: Alsa
    channels: 2
    device: "hw:Loopback,1"
    format: S16LE
  playback:
    type: Alsa
    channels: 2
    device: "hw:CARD=b1,DEV=0"
    format: S16LE

filters:
  null_fir:
    type: Conv
    parameters:
      type: File 
      filename: one.txt

pipeline:
  - type: Filter
    channel: 0
    names:
      - null_fir
  - type: Filter
    channel: 1
    names:
      - null_fir
  Reply With Quote
Old 16th September 2020, 07:51 AM   #825
HenrikEnquist is offline HenrikEnquist  Sweden
diyAudio Member
 
Join Date: Apr 2016
Location: Lund
Quote:
Originally Posted by seashell View Post
Hello and thank you for making this project.

I'm hoping to get some help using it on a raspberry pi 4. I downloaded the binary from github and set up an alsa loopback configuration. It works, but I get frequent dropouts in audio playback. They last about a second, but I think that is the time my hdmi audio extractor / receiver DAC chain takes to recover from a break in the stream so I'm pretty sure the actual breaks are short.

They always happen when camilladsp is first started, or returns to playing after going to sleep, but they also happen randomly during normal play.

I'm running 32 bit Raspberry Pi OS on a 2 GB pi 4 and using the PI's HDMI audio output. I've tried to set the priority higher with nice -10 and it helped some with the random drops, but not so much with the early drops.

The first drop typically comes with "warn...: preparing playback" (or words to that effect) but the other drops do not print anything to screen with -v. (And it's hard to tell with the scrolling of -vv.)

Here's a simple test configuration that I believe should be doing nothing but a pass through that causes the problem. I've also tried with actual FIR filters from 8192 to 65536 taps and it seems to make no difference to the drop frequency.


Any ideas? Something obviously stupid in my config perhaps?

The dropouts that happen early and tha random ones later are two somewhat isolated issues.
The two most likely reasons for the random ones are that you are running a too short chunksize, or that there is a rate mismatch between the hdmi output and the loopback. I would suggest enabling rate adjust, which will adjust the rate of the loopback (without any resampling). Add this to the config:
Code:
devices:
  samplerate: 44100
  chunksize: 4096
   silence_threshold: -60
  silence_timeout: 10.0
  enable_rate_adjust: true
  target_level: 2048
  adjust_period: 10
For the early dropouts, this happens sometimes for some systems, because the playback starts too early. Right now it only waits for a few milliseconds, which lets it buffer a few ms of audio before starting. I willl change this so it calculates a suitable delay based on the settings of samplerate, target_level etc.
For now, try just increasing the chunksize to see if that helps.
  Reply With Quote
Old 16th September 2020, 08:15 AM   #826
seashell is offline seashell
diyAudio Member
 
Join Date: Sep 2020
Thanks for the reply. I meant to mention I've tried several power of 2 chunksizes from 1024 up to 32768 or 65536 (I forget which) and the problems persisted. I'll give the rate adjust a try tomorrow and report back how it went.

Also, in case it wasn't clear and matters "one.txt" just contains a single "1.0".
  Reply With Quote
Old 16th September 2020, 12:20 PM   #827
HenrikEnquist is offline HenrikEnquist  Sweden
diyAudio Member
 
Join Date: Apr 2016
Location: Lund
Quote:
Originally Posted by seashell View Post
Thanks for the reply. I meant to mention I've tried several power of 2 chunksizes from 1024 up to 32768 or 65536 (I forget which) and the problems persisted. I'll give the rate adjust a try tomorrow and report back how it went.

Also, in case it wasn't clear and matters "one.txt" just contains a single "1.0".
I think I fixed the early buffer underruns now. When you try again, please use this new version: Release v0.3.2-beta4 * HEnquist/camilladsp * GitHub
  Reply With Quote
Old 16th September 2020, 04:01 PM   #828
seashell is offline seashell
diyAudio Member
 
Join Date: Sep 2020
Wow that was a quick turn around! Thank you.

I just did a short test of the beta version and killing and restarting camilladsp several times while audio was playing indeed showed no dropouts when play started. (Will make it much easier to compare the REQ curves I'm experimenting with.) Also no drops when resuming from sleep and I didn't notice any random drops during a brief time letting it run with rate adjust on.

There were consistent rate adjust messages output typically in the range of 99.96% - 99.98% while running so I believe you are right that the rates don't match. Do you know if that is an alsa configuration issue or a hardware issue (separate clocks?) in the pi?

As beta feedback I'll list the warnings that were printed, but they seem more informational than anything.

Each time I started camilladsp:
"Starting playback from Prepared state"

Each time I resumed after letting the sleep idle occur:
"Prepare playback after buffer underrun"

Of course when the audio stops that seems a natural buffer underrun condition to me.
  Reply With Quote
Old 16th September 2020, 06:21 PM   #829
HenrikEnquist is offline HenrikEnquist  Sweden
diyAudio Member
 
Join Date: Apr 2016
Location: Lund
Quote:
Originally Posted by seashell View Post
Wow that was a quick turn around! Thank you.

I just did a short test of the beta version and killing and restarting camilladsp several times while audio was playing indeed showed no dropouts when play started. (Will make it much easier to compare the REQ curves I'm experimenting with.) Also no drops when resuming from sleep and I didn't notice any random drops during a brief time letting it run with rate adjust on.
Great! Thanks for testing!



Quote:
Originally Posted by seashell View Post
There were consistent rate adjust messages output typically in the range of 99.96% - 99.98% while running so I believe you are right that the rates don't match. Do you know if that is an alsa configuration issue or a hardware issue (separate clocks?) in the pi?
This is perfectly normal, the loopback device and the HDMI output use different clock sources so they will never run at exactly the same rate. But the loopback device has a fine adjustment knob, and I use that to keep the rates matched. The adjustment needs to be done continuously since the rates will drift slightly all the time.



Quote:
Originally Posted by seashell View Post
As beta feedback I'll list the warnings that were printed, but they seem more informational than anything.

Each time I started camilladsp:
"Starting playback from Prepared state"

Each time I resumed after letting the sleep idle occur:
"Prepare playback after buffer underrun"

Of course when the audio stops that seems a natural buffer underrun condition to me.
Oh I was too quick. The "Starting playback from Prepared state" message doesn't mean there is a problem and should not be a warning. I'll change it to info!
"Prepare playback after buffer underrun" happens both after playback has been paused, and when there was an accidental underrun. The playback thread doesn't know why it happened, only that the audio data arrived late. This is why the message is the same in both cases.
  Reply With Quote
Old 16th September 2020, 11:59 PM   #830
seashell is offline seashell
diyAudio Member
 
Join Date: Sep 2020
Quote:
Originally Posted by HenrikEnquist View Post
This is perfectly normal, the loopback device and the HDMI output use different clock sources so they will never run at exactly the same rate.
Thanks. I figured it was likely to be different clocks once I saw the drift. Too bad the virtual loopback interface doesn't get slaved to the clock of the hardware it's outputting to.


Quote:
Originally Posted by HenrikEnquist View Post
Oh I was too quick. The "Starting playback from Prepared state" message doesn't mean there is a problem and should not be a warning. I'll change it to info!
No worries, I really appreciate the quick fix for the startup issue. As I said I thought the warnings were more informational.

Quote:
Originally Posted by HenrikEnquist View Post
"Prepare playback after buffer underrun" happens both after playback has been paused, and when there was an accidental underrun. The playback thread doesn't know why it happened, only that the audio data arrived late. This is why the message is the same in both cases.
Does the playback thread know it's gone to sleep? If so maybe you could suppress the warning from the first underflow after wake up. Purely cosmetic so if it's not trivial of course leave it as is.

Your websocket configuration option is great. I just tossed together a super quick webpage with buttons for my various REQ test filters. Once I changed the pass through to be a binary file the same length as all the other filters (1.0 followed by zeros) it's really fast and smooth to switch between the filters. Just click a button and there's only the smallest of interruptions in playback.

So much better than what I was doing which was killing camilladsp from the command line and then up arrowing back to whatever mode I wanted to compare. Buttons are easier to use and the short reload time for the filters is much better for A/B comparison.

It will be great in the end too as this will be a headless system controlled via a browser and now I know it will be easy to have a page with a set of filters to choose based on the music/mood/volume level (loudness curves). No need for any server side code at all. I can just sneak an extra webpage into whatever web based music GUI I use. Awesome.
  Reply With Quote

Reply


CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc.Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
The room correction or speaker correction? What can we do with dsp power now availabl Raimonds Full Range 233 28th January 2017 07:51 AM
Introducing OpenDRC, Open Digital Room Correction engine minidsp miniDSP 20 20th January 2016 05:37 PM
What the difference between dsp room correction eq and software correction erez1012 PC Based 0 10th March 2014 07:07 PM
Writing a Cross-Platform, Free Software Modeling Tool and TS-Parameter DB justinzane Software Tools 6 31st December 2013 06:55 AM
FS: DAC, room-correction, active crossovers, amp, speakers! taloyd Swap Meet 4 14th April 2009 03:16 PM


New To Site? Need Help?

All times are GMT. The time now is 05:33 AM.


Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2020 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 14.29%
vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2020 DragonByte Technologies Ltd.
Copyright ©1999-2020 diyAudio
Wiki