Feature request - overlay for remapping audio to GPIO pins

[stefandz]

Hello - this is a follow-up to me showing my ignorance on the forums (and PhilE - who I imagine is @pelwell here) suggesting that I post a request here.

I am trying to remap the PWM audio from the pins connected to the onboard 3.5mm socket to pins 32 and 33 on the GPIO socket. So far I was achieving this by adding the following to /boot/config.txt

dtoverlay=pwm-2chan,pin=12,pin2=13,func=4,func2=4

However, as Phil points out this loads the driver twice (I think) and certainly also leaves audio coming out of the 3.5mm socket. Would it be possible to ask for someone's help in writing an overlay that actually remaps the audio properly? (and that the user can disable if they would like audio back in the normal place)

All help gratefully received.

[P33M]

The preferred method is to rewrite the relevant section in dt-blob.bin (which is primarily Videocore-based GPIO setup on a per-model basis).

The source DTS is here: https://github.com/raspberrypi/documentation/blob/master/configuration/images/dt-blob.dts and it's simple enough to change pin 40/45 to 12/13.

Docs page here tells you how to insert the modified dt-blob: https://www.raspberrypi.org/documentation/configuration/pin-configuration.md

[pelwell]

I woudn't say it was preferred - the dt-blob is a monolithic monstrosity. Edit once and forever have to keep it up-to-date.

All you have to do is choose a DT node that doesn't have an existing pinctrl section and add one - the "audio" node is the obvious one.

It would look something like this (untested):

/dts-v1/;
/plugin/;

/ {
        compatible = "brcm,bcm2708";

        fragment@0 {
                target = <&gpio>;
                __overlay__ {
                        audio_pins: audio_pins {
                                brcm,pins = <40 45 12 13>;
                                brcm,function = <0 0 4 4>; /* in in alt0 alt0 */
                        };
                };
        };

        fragment@1 {
                target = <&audio>;
                __overlay__ {
                        pinctrl-names = "default";
                        pinctrl-0 = <&audio_pins>;
                };
        };
};

[ EDIT: pinctrl-name corrected to pinctrl-names ]

[stefandz]

Thanks for this @pelwell (sorry for the delay in replying!). Am I correct in thinking that I would use the code snippet as a .dts file, before compiling it to a .dtb (with the -@ argument to allow unresolved references), and then getting it onto the /boot partition, along with adding dtoverlay=name-of-device to /boot/config.txt - is that everything? Once I have this debugged I can obviously submit a PR to have it included in future releases of Raspberry Pi Linux I guess, which should filter down to Raspbian.

If I am getting any of this drastically wrong please let me know!

[pelwell]

@stefandz That looks broadly right, with the proviso that different models use different pins for PWM audio. Having said that, I haven't got it to work yet. For reasons I haven't managed to figure out the pinctrl section is being ignored or at least not taking effect. I'll report back when I make some progress.

[karrika]

I have a tested setup for mapping the audio pins to 12, 13. There is also step by step instructions for creating the dt blob and programming it into an eeprom so it works as soon as the HAT is put on top of the RPi. See at the end of the page in http://discohat.com/miscap/.

[pelwell]

Thanks for the suggestion. By the looks of it I'd say that works almost by accident. What you are doing is enabling the PWM driver, which is not the same as the PWM audio driver - just basic perod+duty cycle stuff. But by getting it to request the PWM function on pins 12 & 13 you are achieving the objective. What I'm trying to do is get the pins assigned to the audio node.

I'm also concerned that your overlay leaves the PWM functions multiply mapped, although it appears to be working for you. Once I've got pins allocated for the audio node I'll get the standard DTBs to request the per-platform standard pins, then all an overlay would have to do is overwrite those pin assignments.

[karrika]

Thank you for the feedback. As a normal user I did not understand the difference between pwm and audio node. I have to change the src to use audio node instead. Perhaps later today when I get home. It would be nice to do things correctly.

[stefandz]

Thank you everyone for your valuable (and generous) time contributions to this. If there's anything I can be doing to help, please let me know! BTW, I really like your HAT, @karrika 👍

[pelwell]

Duh! It really helps if you call the property pinctrl-names (note the plural); with that change, it works as expected. I've edited the post above to correct it.

I'll have a think about the best way to make this work on all platforms. My current proposal is:

1. Add audio_pins to the base DTBs.
2. Add parameters to modify them.
3. Get the firmware to use those parameters to select the pins.
4. Make the firmware use the DT audio_pins values when setting the initial pin functions. The intention is make the system act as if the audio pins were inputs before the kernel starts (i.e. no need to restore the usual pins to inputs), but still set the pin functions in the firmware in case other OSs rely on it.

[pelwell]

The firmware change for this went in at the end of last month. I've now pushed the DTB changes that define the audio_pins node for all the Pi models with audio outputs, to be picked up by the next build.

With these in place, the overlay required to remap the output to 12 & 13 now looks like this:

/dts-v1/;
/plugin/;

/ {
        compatible = "brcm,bcm2708";

        fragment@0 {
                target = <&audio_pins>;
                __overlay__ {
                        brcm,pins = <12 13>;
                        brcm,function = <4>; /* alt0 */
                };
        };
};

Note that you can also disable the PWM output with an empty "brcm.pins" property.

[stefandz]

Thanks very much for this @pelwell (and everyone else involved). I will try testing this out today on as many platforms as I can get my hands on.

[Ruffio]

@stefandz as a fix for your issue has been implemented, please try a firmware upgrade and confirm that is has been resolved by closing this issue. Thanks.

[stefandz]

@Ruffio will try to test this during the week - sorry for the delay at this end

[stefandz]

Tested and confirmed working on Raspberry Pi 2 B and Raspberry Pi 3. On the Zero, however, the audio channels are reversed - this is true for both versions 1.2 and 1.3. What is the recommended way of allowing for this - something within the overlay or loading different overlays for different models?

I don't have access to a Pi 1 A+ or B+ for testing - should I expect those to behave like the Zero or the 2/3? Also, I am using a single .dtbo file for all testing, compiled on a Pi3 - is this best practice?

Thank you for all your help on this so far, and apologies that it has taken me so long to get testing finished.

[pelwell]

On early Pis (Models A & B), onboard audio uses PWM0 to drive the left channel of the audio jack and PWM1 to drive the right. With the appearance of the B+ this mapping got reversed (essentially by accident), but the firmware has the ability to swap the channels over so the end result is correct. This swapping is controlled by the pin allocations as read from the dt-blob, either an external dt-blob.bin or the built-in default version, but PiZero normally has no audio jack so there is no swap.

When you use the overlay, pins 12 and 13 are mapped to PWM0 and PWM0 respectively, so audio left should always be sent to 12 and right to 13 for all models EXCEPT that the above swapping is still applied because the firmware doesn't notice that it is no longer needed. The end result is that A+, B+, 2B and 3B have right on 12 and left on 13, while the other Pis have the channels the right way round.

I'll have a think about a fix.

[stefandz]

Thanks for the explanation, @pelwell. I am just as happy to make the fix two overlays, one for the Zero and one for all other Pis if that helps (although from what you're saying, that might get broken in future updates).

[pelwell]

That's actually not an option because you can't map PWM0 to pin 13 and PWM1 to 12. You could use a custom dt-blob.bin, but that can lead to problems with future releases so is best avoided if possible.

[stefandz]

Ah sorry, my misunderstanding. I feel this might be useful to resolve for others who wish to have audio out on the Zero. Do let me know if I can help testing (I promise to be on it quicker this time around - although I am out on holiday for the last two weeks of August).

[stefandz]

Since using this overlay gives the same L-R swapping as my cludgy bit of /boot/config.txt dtoverlay=... nonsense and we're about to release a Debian package for our product, I feel I should get the overlay working for now (with a user note to swap L-R some other way as a workaround).

What's the best way to do this so that the overlay is automatically included if I (as a user) run sudo apt-get dist-upgrade? Or is it equally good form to put the compiled overlay inside the Debian package - and if so, where within the package should it live?

[pelwell]

The rpi-update firmware released on the 16th includes a fix for the L-R swap on 12 & 13 ("firmware: platform: Don't swap audio L&R if using GPIOs 12&13") - see if it works for you.

I can't help you with Debian packaging matters - @XECDesign is our expert. We have always been very wary of editing config.txt during upgrades, but appending a line if it doesn't exist is about as safe as it gets.

[stefandz]

Thanks @pelwell - I shall ask @XECDesign. I wouldn't want to goof around with config.txt during an upgrade - merely ensure that the correct overlay is part of the latest upgrade / release and then appending a line if it doesn't exist as part of the Debian package postinst. I shall also test the L-R swap now - thanks again for everything.

[stefandz]

OK @pelwell - strangely now when I add this overlay to /boot/config.txt I get no audio out at all. Pretty sure everything is correctly written / located / compiled etc - using your snippet from here named as picap-overlay.dts and then compiling it to picap.dtbo using dtc -@ -I dts -O dtb -o picap.dtbo picap-overlay.dts. Going back to the example in my first comment works (albeit with audio reversed on the Zero).

Am I doing something silly here? I am as up-to-date as sudo apt-get update && sudo apt-get dist-upgrade && sync && sudo reboot will get me.

[JamesH65]

Closing due to lack of activity. Reopen if you feel this issue is still relevant.
Closing this issue as questions answered/issue resolved.