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 17th September 2020, 01:08 AM   #831
seashell is offline seashell
diyAudio Member
 
Join Date: Sep 2020
Sorry for posting a second time so quickly, but I just noticed something odd with the configuration reloading. Whether I do it via the websocket or by copying over the current config file and sending sighup the volume gets lowered from when I first start camilladsp from the command line with a given filter configuration. Since you NOP requests to change when the configuration hasn't changed (makes sense) you have to switch to another filter and back to hear this.

My filters are all the same length, and all normalized such that the mean squared value of their taps is 1.0.

Example:
Code:
cp cfg1.yaml cfg0.yaml
camilladsp cfg0.yaml
# Sound starts at certain volume

# In another terminal
cp cfg2.yaml cfg0.yaml
kill -1 {camilladsp pid}
# New filters loaded, but volume is lower.  Is it the new filter?
cp cfg1.yaml cfg0.yaml
kill -1 {camilladsp pid}
# No because the original filter is now loaded but volume is still lower.
# Stop camilladsp (ctrl-c, kill, whatever)

camilladsp cfg0.yaml
# Volume is back at original higher level
  Reply With Quote
Old 17th September 2020, 07:15 AM   #832
HenrikEnquist is offline HenrikEnquist  Sweden
diyAudio Member
 
Join Date: Apr 2016
Location: Lund
Quote:
Originally Posted by seashell View Post
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.
No it doesn't know, it only waits for the next audio chunk. I would like to improve this at some point, and send it a message so it knows the capture is paused. I didn't get around to it since the buffer underruns don't seem to cause any troubles, and the only real "problem" is the unnecessary warning. But I will fix it at some point!
  Reply With Quote
Old 17th September 2020, 07:29 AM   #833
HenrikEnquist is offline HenrikEnquist  Sweden
diyAudio Member
 
Join Date: Apr 2016
Location: Lund
Quote:
Originally Posted by seashell View Post
Sorry for posting a second time so quickly, but I just noticed something odd with the configuration reloading. Whether I do it via the websocket or by copying over the current config file and sending sighup the volume gets lowered from when I first start camilladsp from the command line with a given filter configuration. Since you NOP requests to change when the configuration hasn't changed (makes sense) you have to switch to another filter and back to hear this.

My filters are all the same length, and all normalized such that the mean squared value of their taps is 1.0.
Thanks for the detailed description! I didn't need to try it myself, I could find the problem right away.
When starting from scratch, and when reloading, the coefficients are read using different functions. The one for reloading has a forgotten factor 2 which was already fixed in the other one.
Compare: camilladsp/fftconv.rs at master * HEnquist/camilladsp * GitHub
with: camilladsp/fftconv.rs at master * HEnquist/camilladsp * GitHub


There will be a new beta tonight.
(btw this is a nice example of why code duplication is bad!)


And please keep reporting bugs if you find them
  Reply With Quote
Old 17th September 2020, 04:15 PM   #834
seashell is offline seashell
diyAudio Member
 
Join Date: Sep 2020
I figured it was two different read paths, although I didn't know where in your code to start looking. Agreed that eventually config parsing should probably be rolled into one routine that can be called on start and reload.

I'll toss in a few other feature requests if you don't mind.

It would be nice if warnings were available on the websocket. That way a headless system could say display a clip indicator.

Maybe this is already in place and i just missed it, but some discussion in the documentation on proper scaling of FIR coefficients as different convolvers want different things. Some want them between +/-1, some between +/-32768, etc. I assume the scaling by n-coeffs you're doing has something to do with the gain through an fft/invfft transform pair.

I'm sure this one is annoying as it probably goes into certificate hassles, but browsers these days will not allow ws connections to be made from an https page. Only wss connections. I found that out when I tried to put the webpage on a server on a machine other than the RPI.
  Reply With Quote
Old 17th September 2020, 11:38 PM   #835
HenrikEnquist is offline HenrikEnquist  Sweden
diyAudio Member
 
Join Date: Apr 2016
Location: Lund
Quote:
Originally Posted by seashell View Post
I figured it was two different read paths, although I didn't know where in your code to start looking. Agreed that eventually config parsing should probably be rolled into one routine that can be called on start and reload.
Fixed and a newly built beta5 is available.



Quote:
Originally Posted by seashell View Post
I'll toss in a few other feature requests if you don't mind.

It would be nice if warnings were available on the websocket. That way a headless system could say display a clip indicator.
Sure, I'm always interested in new ideas! Providing the logger output on the websocket would be possible but it would add a fair bit of complexity. You would also need to do a lot of parsing of the messages to get what you want.

What info are you missing on the websocket as it is? It's probably easier to just add the missing bits there.



Quote:
Originally Posted by seashell View Post
Maybe this is already in place and i just missed it, but some discussion in the documentation on proper scaling of FIR coefficients as different convolvers want different things. Some want them between +/-1, some between +/-32768, etc. I assume the scaling by n-coeffs you're doing has something to do with the gain through an fft/invfft transform pair.
I have picked what seems to be the most common way. If the coefficients are one of the integer formats, the value range is the full range of the integer type, -2^31 to (2^31-1) for S32LE for example. For Float, the range is -1.0 to +1.0. I will add something in the readme about this.




Quote:
Originally Posted by seashell View Post

I'm sure this one is annoying as it probably goes into certificate hassles, but browsers these days will not allow ws connections to be made from an https page. Only wss connections. I found that out when I tried to put the webpage on a server on a machine other than the RPI.
My intention with the websocket server was that it should be used locally with for example a python client. That it could be used directly from a browser is just a bonus, but I see how it can be useful. I'll take a look to see how difficult it would be to add wss.
  Reply With Quote
Old 18th September 2020, 12:55 AM   #836
seashell is offline seashell
diyAudio Member
 
Join Date: Sep 2020
Quote:
Originally Posted by HenrikEnquist View Post
Fixed and a newly built beta5 is available.
Downloaded and confirmed deleting a divide by 2 eliminates a divide by 2. :P Thanks again for pushing a quick fix.

Quote:
Originally Posted by HenrikEnquist View Post
Sure, I'm always interested in new ideas! Providing the logger output on the websocket would be possible but it would add a fair bit of complexity. You would also need to do a lot of parsing of the messages to get what you want.
I'm specifically interested in clipping warnings. I'd be fine with all warnings/errors even just as a copy of what you throw to std out to make it easier on you. Should probably only be sent after a client sends a command to turn them on though. That way for people who just want a quick toggle control or the like they don't need to worry about handling incoming packets.

Quote:
Originally Posted by HenrikEnquist View Post
My intention with the websocket server was that it should be used locally with for example a python client. That it could be used directly from a browser is just a bonus, but I see how it can be useful. I'll take a look to see how difficult it would be to add wss.
And here I was thinking you intentionally chose websocket so it could be controlled from a browser. I'll say again really handy though. A few lines of javascript vs a whole cgi/wsgi/php front end/back end setup. Plus it doesn't get much easier for create a few buttons than a webpage these days.

Presuming you didn't write your own websocket gateway library hopefully it's just something that can be turned on in the one you use.

Fortunately my pi's server doesn't serve the main pages using https yet, so I can run my script on the pi itself with ws instead of wss and use it from any browser. So it's certainly not critical for me.

Browsers are getting more and more pushy about https though. I have some older hardware with embedded servers that will only ever be http and the stupid browsers are constantly wanting to push me to https for them even without any "https everywhere" type extensions or settings turned on. So annoying. Yes browser, I REALLY did mean to type http:// not https://. Stop autocorrecting me. /rant
  Reply With Quote
Old 18th September 2020, 04:23 AM   #837
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
Quote:
Browsers are getting more and more pushy about https though. I have some older hardware with embedded servers that will only ever be http and the stupid browsers are constantly wanting to push me to https for them even without any "https everywhere" type extensions or settings turned on. So annoying. Yes browser, I REALLY did mean to type http:// not https://.
So very true. Plus they will limit accepted SSL certificate lifetime to 1 year. I wonder how embedded devices will handle that (will have to figure out myself too).
  Reply With Quote
Old 18th September 2020, 07:34 PM   #838
HenrikEnquist is offline HenrikEnquist  Sweden
diyAudio Member
 
Join Date: Apr 2016
Location: Lund
So I have read up a little about wss. It's easy to implement, just need to load a certificate from file and set the websocket server up to use it.
But, I discovered that the websocket library I'm using has been without a maintainer for the last 6 months and it doesn't look like anyone is taking over. Should have researched that a bit better when I added it.

Since I have no interest in maintaining the library myself, the best I can do is probably to switch to another one. So instead of building more stuff around the present one I will extend this to a little project:
- Change websocket library
- Implement wss
- Add clipping, buffer levels and other missing stuff to the websocket server
- Replace my home-made message protocol with json (should make it easier to use in the browser!)
- Update pyCamillaDSP to the new protocol.

This will probably keep me busy for a while



I also looked at redirecting the console log messages to the websocket. It seems doable, but will require a large effort. It also means the websocket server would need to dig its roots much deeper into the rest of the code, so keeping it as an optional feature will be a mess. I'll put it on the maybe-some-day-list..


The reason I went with websocket and not a plain socket is that I wanted to be able to send messages consisting of many lines. With a socket it's easy to send and receive single lines, but as soon as a message has more than one line you can't just look at line break to know the message is complete. The websocket protocol handles this nicely, so I don't need to
  Reply With Quote
Old 18th September 2020, 07:56 PM   #839
Tfive is offline Tfive  Germany
diyAudio Member
 
Tfive's Avatar
 
Join Date: Jun 2018
Location: Straubing
just a quick recommendation: stick with websockets, plain socket communication can/will be a PITA going forward
__________________
Want more of the good stuff? -> https://t-5.eu/
  Reply With Quote
Old 18th September 2020, 08:22 PM   #840
HenrikEnquist is offline HenrikEnquist  Sweden
diyAudio Member
 
Join Date: Apr 2016
Location: Lund
Quote:
Originally Posted by Tfive View Post
just a quick recommendation: stick with websockets, plain socket communication can/will be a PITA going forward
I will keep using webocket! I'll just switch to a library that is maintaned. This is currently my top candidate: https://crates.io/crates/tungstenite
  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 04:08 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