I can indeed confirm that the "windowsbuild" branch builds fine by default on Mac as well, also with FFTW enabled.
While your on it, when you now use cpal, I think you can actually build a version of CamillaDSP that can run in the browser, right? With Emscripten you should be able to build a webassembly version. Wouldn't that be cool 🙂
While your on it, when you now use cpal, I think you can actually build a version of CamillaDSP that can run in the browser, right? With Emscripten you should be able to build a webassembly version. Wouldn't that be cool 🙂
Major update! CamillaDSP goes cross-platform 🙂
The "develop" branch has been updated and now has support for both Wasapi on Windows and CoreAudio on macOS!
It should be considered an alpha version for now, since it hasn't been tested much beyond that it runs and can play sound. Any feedback is appreciated 🙂
The "develop" branch has been updated and now has support for both Wasapi on Windows and CoreAudio on macOS!
It should be considered an alpha version for now, since it hasn't been tested much beyond that it runs and can play sound. Any feedback is appreciated 🙂
Another update, pre-built binaries for the most common systems! These are built and published automatically for each new release.
I'm currently building for Linux on AMD64, Linux on armv7 (Raspberry Pi), Windows on AMD64 and macOS on AMD64.
(note: "AMD64" is one of the names for 64-bit Intel or AMD cpus, also called "x86_64" or just "x64")
See the Releases page here: Releases * HEnquist/camilladsp * GitHub. Click "Assets" to view the files.
The Readme for the develop branch has also been updated with this info: camilladsp/README.md at develop * HEnquist/camilladsp * GitHub
I'm currently building for Linux on AMD64, Linux on armv7 (Raspberry Pi), Windows on AMD64 and macOS on AMD64.
(note: "AMD64" is one of the names for 64-bit Intel or AMD cpus, also called "x86_64" or just "x64")
See the Releases page here: Releases * HEnquist/camilladsp * GitHub. Click "Assets" to view the files.
The Readme for the develop branch has also been updated with this info: camilladsp/README.md at develop * HEnquist/camilladsp * GitHub
Found it. For mac you supplied a ".dms" file (?), usually we see a .dmg one. None of my extractors was able to open that download.
//
//
It's an uncompressed executable! Just make it executable with "chmod a+x camilladsp-macos-amd64". You will also need to mark it as allowed to run, click the question mark in the dialog that pops up when you try to run it with for example "./camilladsp-macos-amd64 --help".Maybe you want to use .zip for macos also, some do.
//
Åhå 🙂
OK - I found out that Safari adds that filtype (.dms) and its an old bug...
:./camilladsp-macos-amd64.app --help
CamillaDSP 0.3.0
Henrik Enquist <henrik.enquist@gmail.com>
A flexible tool for processing audio
Built with features: cpal-backend, socketserver
USAGE:
camilladsp-macos-amd64.app [FLAGS] [OPTIONS] <configfile>
FLAGS:
-c, --check Check config file and exit
-h, --help Prints help information
-V, --version Prints version information
-v Increase message verbosity
-w, --wait Wait for config from websocket
OPTIONS:
-p, --port <port> Port for websocket server
ARGS:
<configfile> The configuration file to use
(base)
Bloody great ;-D
//
OK - I found out that Safari adds that filtype (.dms) and its an old bug...
:./camilladsp-macos-amd64.app --help
CamillaDSP 0.3.0
Henrik Enquist <henrik.enquist@gmail.com>
A flexible tool for processing audio
Built with features: cpal-backend, socketserver
USAGE:
camilladsp-macos-amd64.app [FLAGS] [OPTIONS] <configfile>
FLAGS:
-c, --check Check config file and exit
-h, --help Prints help information
-V, --version Prints version information
-v Increase message verbosity
-w, --wait Wait for config from websocket
OPTIONS:
-p, --port <port> Port for websocket server
ARGS:
<configfile> The configuration file to use
(base)
Bloody great ;-D
//
So maybe you should .zip it to avoid the above...
Now, if one could make this integrate so that I could still use my old trusted Squeezserver on my Mac Mini, I would be dandy.
//
Now, if one could make this integrate so that I could still use my old trusted Squeezserver on my Mac Mini, I would be dandy.
//
Probably a good idea. What do mac users prefer, .zip or .tar.gz?So maybe you should .zip it to avoid the above...
Now, if one could make this integrate so that I could still use my old trusted Squeezserver on my Mac Mini, I would be dandy.
//
I updated my build scripts, so now the binary downloads are compressed.
Linux: .tar.gz
Mac/Win: .zip
I have played a bit with the ASIO support of the CPAL lib. Unfortunately in the current state the it's not very useful. The main problem is that CPAL only supports 16-bit integers and 32-bit floats, and for ASIO 24&32-bit int gets converted to 16-bit ints. That means it's stuck at 16 bits for most hardware. 32-bit float would have been a lot better, then we at least get the equivalent of 24 bits.
CPAL will get support for more sample formats some time in the future, and that should take care of this.
Linux: .tar.gz
Mac/Win: .zip
I have played a bit with the ASIO support of the CPAL lib. Unfortunately in the current state the it's not very useful. The main problem is that CPAL only supports 16-bit integers and 32-bit floats, and for ASIO 24&32-bit int gets converted to 16-bit ints. That means it's stuck at 16 bits for most hardware. 32-bit float would have been a lot better, then we at least get the equivalent of 24 bits.
CPAL will get support for more sample formats some time in the future, and that should take care of this.
Probably a good idea. What do mac users prefer, .zip or .tar.gz?
.dmg :-D
//
PS: zip ok but probably mac user would rather be associated with Linux so tar.gz is also ok
Last edited:
.dmg :-D
//
PS: zip ok but probably mac user would rather be associated with Linux so tar.gz is also ok
Haha ok I'll switch to tar.gz.
About the websocket server. I want to add some functions to it and I have realized that the simple protocol I made up is too simple and actually makes things more difficult. So I want to scrap it and replace with something based on json. That will make it much easier to add new commands, and much better for JavaScript clients. Existing Python scripts will need to be updated but that should be fairly quick.
CPAL will get support for more sample formats some time in the future, and that should take care of this.
Do I understand correctly that it would perhaps require just adding F32/ASIOSTInt32LSB and F32/ASIOSTInt24LSB combinations to process_output_callback cpal/stream.rs at fe22704d4adc2795f33f2e298c5450ece476d58c * RustAudio/cpal * GitHub and process_input_callback cpal/stream.rs at fe22704d4adc2795f33f2e298c5450ece476d58c * RustAudio/cpal * GitHub and maybe extending some config param checks? F32 is a powerful format, used e.g. by jackd.
Yes I think it's pretty easy to fix, I might give it a go and submit a PR.Do I understand correctly that it would perhaps require just adding F32/ASIOSTInt32LSB and F32/ASIOSTInt24LSB combinations to process_output_callback cpal/stream.rs at fe22704d4adc2795f33f2e298c5450ece476d58c * RustAudio/cpal * GitHub and process_input_callback cpal/stream.rs at fe22704d4adc2795f33f2e298c5450ece476d58c * RustAudio/cpal * GitHub and maybe extending some config param checks? F32 is a powerful format, used e.g. by jackd.
I think it's enough to change in the places you found, and the place where they map Cpal <> Asio formats: cpal/device.rs at fe22704d4adc2795f33f2e298c5450ece476d58c * RustAudio/cpal * GitHub
There is comment there:
I have no idea why they decided to map to I16, seems like a weird decision..// NOTE: While ASIO does not support these formats directly, the stream callback created by
// CPAL supports converting back and forth between the following. This is because many ASIO
// drivers only support `Int32` formats, while CPAL does not support this format at all. We
// allow for this implicit conversion temporarily until CPAL gets support for an `I32`
// format.
sys::AsioSampleType::ASIOSTInt32MSB => SampleFormat::I16,
sys::AsioSampleType::ASIOSTInt32LSB => SampleFormat::I16,
New version up, 0.3.1-alpha. This supports rate adjust via the resampler also for Wasapi and CoreAudio.
- Home
- Source & Line
- PC Based
- CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc