@t-gh-ctrl : Thanks for your update. It confirms that firmware cannot depend only on the playback-off request. Kudos to you perseverance and not getting put off by their standard initial response.
I'm experimenting with channel labels and I think I have something that could work.
It's made up of two ideas. The first is this. The number of channels is first determined at the capture device, and then it can only change by adding a mixer. Since these are the only two places that can decide the number of channels, these are also the places to assign labels to those channels. The playback device also defines a number of channels, but this isn't independent since it must match the output of the pipeline.
The second idea is that the largest benefit of labels is to make the gui easier to use. So as long as the labels are available in the gui, the config format can stay mostly the same and still use numbers for the channels.
The capture device has a list of labels:
Mixers also have a list of labels for the output channels:
It still uses the channel number to select source and destination channels, but also shows the label for the selected channel. The input labels are extracted from the pipeline. In this proof of concept it simply searches the pipeline for a mixer step using this mixer. If it finds one, it uses the labels from there. If not, it falls back to just numbers. It's probably almost never happens, but it's allowed to use the same mixer in several pipeline steps. In this case, it will only show the input labels from the first step. Maybe good enough, let's see.
Filter steps in the pipeline use labels if available for selecting what channel(s) to process:
And the pipeline plot of course also use them:
The way the gui is designed, the labels have to be fairly short to fit in the layout.
The advantage of this approach is that it's very simple to implement in camilladsp itself. It only needs to accept the new labels properties, but doesn't have to care about them. The downside is that this doesn't make it any easier to write configs by hand.
It's made up of two ideas. The first is this. The number of channels is first determined at the capture device, and then it can only change by adding a mixer. Since these are the only two places that can decide the number of channels, these are also the places to assign labels to those channels. The playback device also defines a number of channels, but this isn't independent since it must match the output of the pipeline.
The second idea is that the largest benefit of labels is to make the gui easier to use. So as long as the labels are available in the gui, the config format can stay mostly the same and still use numbers for the channels.
The capture device has a list of labels:
Mixers also have a list of labels for the output channels:
It still uses the channel number to select source and destination channels, but also shows the label for the selected channel. The input labels are extracted from the pipeline. In this proof of concept it simply searches the pipeline for a mixer step using this mixer. If it finds one, it uses the labels from there. If not, it falls back to just numbers. It's probably almost never happens, but it's allowed to use the same mixer in several pipeline steps. In this case, it will only show the input labels from the first step. Maybe good enough, let's see.
Filter steps in the pipeline use labels if available for selecting what channel(s) to process:
And the pipeline plot of course also use them:
The way the gui is designed, the labels have to be fairly short to fit in the layout.
The advantage of this approach is that it's very simple to implement in camilladsp itself. It only needs to accept the new labels properties, but doesn't have to care about them. The downside is that this doesn't make it any easier to write configs by hand.
Labels.
Looks really good, simple is best.
It appears that the labels are entered as a comma delimited list. You say "the labels have to be fairly short to fit in the layout" - how many characters are you allowing per label? 2 or 3 should be sufficient, however, the config for my Motu Ultralite Mk.5 has 18 channels for the Output Device (of which I use only 6). Creating the comma delimited list is the only downside I can see, but a list of ",,LB,RB,LM,RM,LH,RH," should label the channels appropriately.
Look forward to trying it out.
Looks really good, simple is best.
It appears that the labels are entered as a comma delimited list. You say "the labels have to be fairly short to fit in the layout" - how many characters are you allowing per label? 2 or 3 should be sufficient, however, the config for my Motu Ultralite Mk.5 has 18 channels for the Output Device (of which I use only 6). Creating the comma delimited list is the only downside I can see, but a list of ",,LB,RB,LM,RM,LH,RH," should label the channels appropriately.
Look forward to trying it out.
That's only for now (because it was quick to get working), I'll change it for something easier to use.
There is no limit for now but there likely should be one.
I'm aware that many interfaces have a quite large number of channels. You should not be forced to give labels for all, only the ones you need.
I have a 2->4 channel mixer. I want to filter, delay and attenuate a version of each input channel (L/R) and add it to two of the 4 output channels (LF branch in a 2 way active stereo setup).
//
//
Last edited:
If one happen to "view" a faulty config in pipeline, the screen goes black and one cant get back to ones hard earned, albeit faulty, efforts...
//
//
I tweaked an existing config by upping the Mixer from 4->6 but hadn't followed up yet in the Pipline... the Pipeline tab showed a red triangle. Went into the Pipline tab and used the graphing button without fixing the faults... bom...
//
//
Hi. I am back after a while to pick up where I left and update the latest to use the aggregate audio devices on macOS. Then I found that I am having a problem with the conf file that worked with older version. The error boils down to finding the matching playback format, trying to use macbook air speakers as the test output. I don't have any DAC handy yet. How can I fix this?
Try just removing the playback sample format from the config. That should make it use whatever format the device is already set to.
If I wanted to feed my ch4 and ch5 from the input and not after the first mixer - how to do that?
Do I need yet a mixer there in the beginning?
I want a place to enter global EQ on ch0-4 but I dont want that EQ on ch4-5...
//
Do I need yet a mixer there in the beginning?
I want a place to enter global EQ on ch0-4 but I dont want that EQ on ch4-5...
//
May I tweak the existing one or do I have to do it from scratch?
I put in a basic 2->4 on top but config har errors..
I'm obviously always confused but these mixer setups and how to do them 🙂
//
I put in a basic 2->4 on top but config har errors..
I'm obviously always confused but these mixer setups and how to do them 🙂
//
The existing mixer expects 2 incoming channels, but after putting in the mixer, it gets 4. You just need to change the number of input channels on that one and update the mappings. After that you should be good.
Hi everyone,
I wanted to share a quick update on my project with the HiFiBerry DAC8X and CamillaDSP. I received my components and tested the balanced output configuration as suggested. It works perfectly! The setup with CamillaDSP was straightforward, and the sound quality is fantastic. Thanks for the great advice!
Best,
Matthew