A few questions on controlling audio input gain and output volume

Pisound Micro
1

Hi,
Really nice that Pisound micro eventually made it to production! I’m reading its docs (Pisound Micro Mapper - Pisound Micro Documentation) and I see how one can control ALSA’s playback volume. The provided example is with a rotary encoder.

  1. If done with a potentiometer, a single one is enough to control both audio output channels? Or do I need a sterer pot for that?
  2. Is it possible to change the pot’s profile, from linear to turn it to logarithmic so you can get a better volume control?
  3. (pretty dummy, I guess) If I use Pure Data with ALSA and control ALSA’s output volume with a pot, that’s enough, right? I don’t need to do anything on the Pd side to control the audio output volume?
  4. Is there some way to control the gain for the audio input, similar to how it is done in Pisound? I couldn’t tell from the examples in the documentation.

Cheers

1 Like
2

One mono pot is enough, it by default should map to both channels, unless you explicitly specify it to work on a single channel in the mapping. Also you can map the same control to multiple parameters.

The ALSA mixer controls themselves are a bit nonlinear, so first give it a try with linear potentiometers. Changing the curve would be possible in Pisound Micro Mapper, but it’s not implemented yet.

Yes, the ALSA mixer controls control the volumes just before the signal reaches the software, and just before it goes to the physical outputs, so in PD, you can pretty much have 100% sound level, and rely on ALSA mixer for adjusting the volume.

The input gain is not identical to Pisound, it’s controlled through the ALSA mixer’s controls.

1 Like
3

Hi Giedrius, thanks for the heads up! A couple more questions:

  1. Can the main audio output and the headphones output be controlled by two separate pots, or do I need to do this in analog circuitry?
  2. Is it possible to provide examples on how to control the input gain? The docs are pretty complete, but I can’t seem to find out how I can go about that.
4

Yes, you can map ALSA mixer volume controls for HP and LINE OUT to separate potentiometers.

You can find all the available ALSA control names using:

amixer -D hw:pisoundmicro controls

Try this config, change the pin to the one you are using:

{
    "$schema": "https://blokas.io/json/pisound-micro-schema.json",
    "version": 1,
    "controls": {
        "pisound-micro": {
            "gain_pot": {
                "type": "analog_in",
                "pin": "B23"
            }
        },
        "alsa": {
            "hw:pisoundmicro": [
                "Capture Volume"
            ]
        }
    },
    "mappings": [
        [ "gain_pot", "->", "Capture Volume" ]
    ]
}

It should control this ALSA mixer control:

image
image147×659 2.49 KB

In the “controls” section, you declare the kinds of controls you want to be using from various different subsystems (Pisound Micro, ALSA, MIDI, OSC). In the “mappings” section you refer to these controls by name (or assigned aliases, useful in case multiple systems have the same name), and define the relations between them. Analog potentiometers should be used as one sided control with <- or -> mapping direction. However, Encoders or some MIDI / OSC controls can be kept in sync, so whenever you change the volume through ALSA mixer directly, the encoder value can be aware of the change, and subsequent rotation of the encoder would be in reference of the new position.

1 Like
5

Finally I’m testing the I/O pins of the pisound micro. I managed to get two pots to control ALSA’s main output and the headphones output, but I can’t get an encoder to be sent to Pd via OSC.

Here’s my mapper.json file:

{
    "$schema": "https://blokas.io/json/pisound-micro-schema.json",
    "version": 1,
    "controls": {
        "pisound-micro": {
            "volume_pot": {
                "type" : "analog_in",
                "pin" : "B33"
            },
            "headphone_pot": {
                "type" : "analog_in",
                "pin" : "B29"
            },
            "encoder_pot": {
                    "type" : "encoder",
                    "pins" : [ "B03", "pull_up", "B04", "pull_up" ]
            }
        },
        "alsa": {
            "hw:pisoundmicro": [
                "Digital Playback Volume", "Headphone Playback Volume"
            ]
        }
    },
    "osc": {
            "sendpd": {
                    "notify": "osc.udp://:8000",
                    "params": {
                            "encval": {
                                    "path": "/main/encoder",
                                    "type": "i"
                            }
                    }
            }
    },
    "mappings" : [
        [ "Digital Playback Volume", "<-", "volume_pot" ],
        [ "Headphone Playback Volume", "<-", "headphone_pot" ],
        [ "sendpd", "<-", "encoder_pot"]
    ]
}

This doesn’t work. Also, the “mappings” I’ve included for the encoder is sort of a wild guess.

If I remove the OSC part (including the “mappings” entry for OSC) but leave the “encoder_pot” entry, it works fine.

6

There’s a couple of mistakes in your json. You should use an editor that support immediate schema validation to detect these errors immediately.

An alternative to such editor is using an online JSON schema validator tool like https://www.jsonschemavalidator.net/ - paste the contents of https://blokas.io/json/pisound-micro-schema.json into the left text box and your JSON config into the right text box and it should show whether there are any syntax or schema validation errors.

Additionally, check the output of pisound-micro-mapper.service to see if there’s any other issues than the JSON itself:

journalctl -u pisound-micro-mapper.service

The 1st issue with the JSON config was that “osc” object should be under “controls” object.

The 2nd issue is that you should be using “encval” instead of “sendpd” for the control name in the mappings section. (encval is a control’s name, sendpd is a sort of a “control server” name, mainly for the case if you’d want to have different OSC addresses for different controls)

Here’s the fixed up config:

{
    "$schema": "https://blokas.io/json/pisound-micro-schema.json",
    "version": 1,
    "controls": {
        "pisound-micro": {
            "volume_pot": {
                "type" : "analog_in",
                "pin" : "B33"
            },
            "headphone_pot": {
                "type" : "analog_in",
                "pin" : "B29"
            },
            "encoder_pot": {
                    "type" : "encoder",
                    "pins" : [ "B03", "pull_up", "B04", "pull_up" ]
            }
        },
        "alsa": {
            "hw:pisoundmicro": [
                "Digital Playback Volume", "Headphone Playback Volume"
            ]
        },
        "osc": {
                "sendpd": {
                        "notify": "osc.udp://:8000",
                        "params": {
                                "encval": {
                                        "path": "/main/encoder",
                                        "type": "i"
                                }
                        }
                }
        }
    },
    "mappings" : [
        [ "Digital Playback Volume", "<-", "volume_pot" ],
        [ "Headphone Playback Volume", "<-", "headphone_pot" ],
        [ "encval", "<-", "encoder_pot"]
    ]
}

To verify that OSC events work, install liblo-tools and run oscdump:

oscdump osc.udp://:8000

and you should see the OSC events as they arrive at that address.

7

Thanks for your reply.

I updated the pisound-micro-mapper.json file with your version and restarted the service. Running oscdump osc.udp://:8000 now gives values from the encoder, but I can’t get them in Pd.

I have this patch:

[netreceive -u -b 8000]
|
[oscparse]
|
[list trim]
|
[print]

but I get nothing in Pd’s console.

8

It does work for me:

image
image1009×490 91.5 KB

Maybe your PD was started with -stderr option or some redirection of its output?

9

Oops, you’re right! Pd’s log was set to 0! Setting it to 2 fixed it. Thanks!

1 Like