Automated conversion of the digital formats to PCM in the input module could allow building a linux/rpi-based AV receiver implementing the usual audio DSP (apart of the fake surround modes, I guess). However, even the cheapest AVR supports all the licenced closed formats out of reach of a linux device. IMO such path would lead to no real value added.
Now finally there are new versions of everything the gui needs to work with camilladsp v0.5
To run the latest you need:
- camilladsp v0.5.0-beta2
- pycamilladsp v0.5.0
- pycamilladsp-plot v0.4.3
- camillagui-backend v0.6.0
I also started a repo to collect scripts for automatic install:
GitHub - HEnquist/camilladsp-setupscripts
For now, there is only one for mac, but I will add for other platforms. Contributed scripts are welcome 🙂
To run the latest you need:
- camilladsp v0.5.0-beta2
- pycamilladsp v0.5.0
- pycamilladsp-plot v0.4.3
- camillagui-backend v0.6.0
I also started a repo to collect scripts for automatic install:
GitHub - HEnquist/camilladsp-setupscripts
For now, there is only one for mac, but I will add for other platforms. Contributed scripts are welcome 🙂
Thank you for new versions. I see there is a slider above State, what does is adjust? Green bars are nice, is it possible to combine with numeric value?
The slider adjusts the volume if you have Volume filters in the pipeline. I probably forgot the help on mouseover for it.
I didn't put any values on the signal level gauges in order to keep the size down there in the left pane. They are intended more as a diagnostic than for precise measurements (and they are probably updating too slowly for that anyway). I think it would be better to have a dedicated status page, with more info and faster update speed for that. We'll see if and when I get to that, the gui stuff is really time consuming..
I didn't put any values on the signal level gauges in order to keep the size down there in the left pane. They are intended more as a diagnostic than for precise measurements (and they are probably updating too slowly for that anyway). I think it would be better to have a dedicated status page, with more info and faster update speed for that. We'll see if and when I get to that, the gui stuff is really time consuming..
Hey Henrik.
I've created a script which installs the ::
- camilladsp v0.5.0-beta2
- pycamilladsp v0.5.0
- pycamilladsp-plot v0.4.3
- camillagui-backend v0.6.0
It's intended for an Raspberry pi (3+4) running armv7 (could be piCorePlayer 6.10). The websocket-client and the necessary py-six, camilladsp and a Startup script for the GUI is downloaded from my Github. Maybe you would like that to reside on your'e own repos?... I can easily change the wget adresses if this is what you like.
Case is with this funny dist., that e.g the camilladsp have to be squashed into this special .tcz filesystem the piCore uses, therefore i had to create them and put them on my own Github.
Jesper.
Last edited:
Good job Jesper!
If the script depends on packages that you build (by hand?) and host on your github account, then it probably makes more sense to keep the installer script there too. And I put a link to it in the readme of my setupscripts repo.
It seems boring to build the camilladsp .tcz by hand every time. Would it be easy to do it with a script? Then I could probably let github do that automatically for each new release.
BTW could you submit the six and websocket packages to the standard picore package repos?
If the script depends on packages that you build (by hand?) and host on your github account, then it probably makes more sense to keep the installer script there too. And I put a link to it in the readme of my setupscripts repo.
It seems boring to build the camilladsp .tcz by hand every time. Would it be easy to do it with a script? Then I could probably let github do that automatically for each new release.
BTW could you submit the six and websocket packages to the standard picore package repos?
Well it's actually not so complicated. I use the (your's) prebuild camilladsp and then i squash it into a camilladsp.tcz ::
Code:
package
└── usr
└── local
└── bin
└── camilladspWhen system boot's, it's packed out and placed in ram/filesystem.
So when you release a new camilladsp, i just have to replace the old one in the squashed package with the new one...
I've tried this some, but never with success... Problem is also that picorePlayer uses her own repos, so i'll rather stay with them as is and located in some github repos.
Jesper.
Newbie Questions
Hi I just started using Camilladsp as integrated into moode 7.0. There are things that I don’t understand as I do not really have a computing background although I am quite familiar with signal processing. I have Camilladsp currently working and applying some high pass filters to the output. Works great at 16/44 but has dropouts (8-10 per album) when I play a 24/94. From what I understand things work as follows.
Data stream is captured
Filter is applied through convolution in time domain (multiply integrate shift)
Data is output
When setting “sample rate” at 44.1 is the bit stream down converted?
Is “extra chunks” actually zero padding in the time domain?
I will have more questions till I fix this.
Hi I just started using Camilladsp as integrated into moode 7.0. There are things that I don’t understand as I do not really have a computing background although I am quite familiar with signal processing. I have Camilladsp currently working and applying some high pass filters to the output. Works great at 16/44 but has dropouts (8-10 per album) when I play a 24/94. From what I understand things work as follows.
Data stream is captured
Filter is applied through convolution in time domain (multiply integrate shift)
Data is output
When setting “sample rate” at 44.1 is the bit stream down converted?
Is “extra chunks” actually zero padding in the time domain?
I will have more questions till I fix this.
More info
I am currently running a raspberry pi 4B (4GB) with an Allo Katana DAC. This can support 32/352.8
My current YAML file is attached. The 24/96 file I am having trouble with does exhibit some clipping in the master which would translate to large bandwidth. So far no dropouts on DSDS64 files, but since it is so seldom it might take a while for it to happen.
I am currently running a raspberry pi 4B (4GB) with an Allo Katana DAC. This can support 32/352.8
My current YAML file is attached. The 24/96 file I am having trouble with does exhibit some clipping in the master which would translate to large bandwidth. So far no dropouts on DSDS64 files, but since it is so seldom it might take a while for it to happen.
Last edited:
I'm have not yet looked at how camilladsp is integrated in moode, but I believe it is done with the cdsp alsa plugin. Does it then switch samplerate on the fly, or does it resample everything to one rate?
Your config file looks fine. That file will only capture and play at 44.1kHz so if you use it with 96kHz or DSD then moode must be resampling for you.
The "extra_samples" option pads with zeros after the stream ends. This is used if you have a long fir filter, to avoid the last fraction of a second of each song to be cut off. In your config there is only biquads which don't give any delay. You can leave it out or set it to 0.
Its only FIR filter that use convolution. Biquads are calculated directly using the difference equation. I'm using transposed direct form 2: Digital biquad filter - Wikipedia
You can get a little clipping from just a highpass with only zero or negative gain. The signal changes a little from any filtering and there can appear new peaks that are higher than before. It's good to always include a -3dB gain filter to make some room.
Your config file looks fine. That file will only capture and play at 44.1kHz so if you use it with 96kHz or DSD then moode must be resampling for you.
The "extra_samples" option pads with zeros after the stream ends. This is used if you have a long fir filter, to avoid the last fraction of a second of each song to be cut off. In your config there is only biquads which don't give any delay. You can leave it out or set it to 0.
Its only FIR filter that use convolution. Biquads are calculated directly using the difference equation. I'm using transposed direct form 2: Digital biquad filter - Wikipedia
You can get a little clipping from just a highpass with only zero or negative gain. The signal changes a little from any filtering and there can appear new peaks that are higher than before. It's good to always include a -3dB gain filter to make some room.
I put in a 3dB pad and no more dropouts! I also increased my sample rate to 384. All is working so far. A wonderful piece of work
devices:
samplerate: 352800
chunksize: 1024
queuelimit: 1
capture:
type: File
channels: 2
filename: "/dev/stdin"
format: S32LE
extra_samples: 8192
playback:
type: Alsa
channels: 2
device: "hw:0,0"
format: S32LE
filters:
gainred:
type: Gain
parameters:
gain: -3.0
inverted: false
hp_802:
type: Biquad
parameters:
type: Highpass
freq: 27
q: 2.0
pipeline:
- type: Filter
channel: 0
names:
- hp_802
- gainred
- type: Filter
channel: 1
names:
- hp_802
- gainred
devices:
samplerate: 352800
chunksize: 1024
queuelimit: 1
capture:
type: File
channels: 2
filename: "/dev/stdin"
format: S32LE
extra_samples: 8192
playback:
type: Alsa
channels: 2
device: "hw:0,0"
format: S32LE
filters:
gainred:
type: Gain
parameters:
gain: -3.0
inverted: false
hp_802:
type: Biquad
parameters:
type: Highpass
freq: 27
q: 2.0
pipeline:
- type: Filter
channel: 0
names:
- hp_802
- gainred
- type: Filter
channel: 1
names:
- hp_802
- gainred
Last edited:
Hey and merry Xmas here...
@Henrik i have a script which installs the newest creations you did 😀
It's here in my new guide/howto ::
SuperPlayer-v3.0/README.md at main * Lykkedk/SuperPlayer-v3.0 * GitHub
Jesper.
@Henrik i have a script which installs the newest creations you did 😀
It's here in my new guide/howto ::
SuperPlayer-v3.0/README.md at main * Lykkedk/SuperPlayer-v3.0 * GitHub
Jesper.
You raise a valid point. I just find AVRs too bulky for my needs with way to many features I wouldn’t need therefore making them costly too. I just like the idea of using something small that I could feed into a Multichannel DAC and power amps. It seems the PI has the horsepower it just doesn’t have the necessary hardware like HDMI input with the associated Dolby licensing.
Now revisions show all of a sudden 🙂
How do I add a filter here?
and there is 2 "Channel 0" in the pipeline plot but only one (implied) in the meny - should be good to name it maybe?
//
How do I add a filter here?
and there is 2 "Channel 0" in the pipeline plot but only one (implied) in the meny - should be good to name it maybe?
//
Attachments
Last edited:
Awesome. I've just installed moode 7. I was going to integrate Camilla into it, but I'm glad that the Moode guys saw the obvious win here and included it. Now I'll just have to find where it is in the UI. I'm also interested in pulling in my analog ADC channels from my Motu 8a into the mix.
I read further in the discussion and apparently you have it running at 384 khz (!) with just a -3db pad in between. What platform are you using. I'm using a Raspberry Pi 4b /w 8gb.
To add a filter before the Mixer, just add a Filter step before the Mixer in the pipeline.
The channel "names" are always just the numbers 0..nbr_channels-1. So before the mixer, you have channels 0 and 1. After the mixer, you have 0,1,2,3. Channel 0 before and channel 0 after the mixer are not the same signal!
Several people have suggested adding names to the channels. The problem with doing that is that it adds quite a bit of complexity to the configuration parsing. This is why I haven't done it. I might give it a try at some point, but not right now.
Oh right, didn't think about that. Yes you will have to start over. Something to work on for the next version 🙂
