NEWBIE - help with volume.py not working..

mtm81

Hi, I've recently started my journey using retropie within my arcade1up machine. All working absolutely fine, however I'm trying to use the existing three stage vol button and one and off two stage switch.

Pi 3b and latest updated version of retropie

I'm using the scripts https://github.com/orlandovald/arcade1up.git which I've installed fine.

Here's the kicker.
The volume - it doesn't work at all. HOWEVER, if I putty into the machine, manually run the volume.py script, I can see that it's outputting correctly and indeed, when I then move the switch - it works perfectly. As soon as I close Putty, the switch on the device stops working. It's as if the script isn't running by itself.
I've been into my rc.local file and can see that the script is being called with sudo python 'script here' &

so to me as a novice - it 'should' be working?

As a second point, and I'm not sure if this is linked? The power switch is a little "odd". If the device is on and the switch is in it's on position - if I then switch to off - it powers down correctly. However, switching then back to "on" doesn't re-power the device.

Occasionally,if I move it between on and off one or two times- it will then come back on - but it's not consistent.

Has anyone seen this kind of issue (particularly the volume issue) before and can offer any insight?

Many thanks for any replies!

ByteThis

@mtm81 There is a dedicated Arcade1up reddit sub that may be of reference : https://www.reddit.com/r/Arcade1Up/

mtm81

@ByteThis think you for the reply, but my issues isn’t necessarily related to arcade1up (kind of)
It’s more that a script I’m referencing in the startup of pi doesn’t appear to run unless I manually run it using putty.
I guess I’m trying to figure out how to trouble shoot that.

mtm81

@mtm81 In a further update to this, I've made some further progress.

When I run the volume.py script within the rc.local file - at that point in time, the default audio device is being seen as "HDMI". However when the emulation has the finished loading - that is correctly detected by the emulation station as being "Headphone". However, because my volume script has already loaded before that point - it never sees that change of audio output from my emulationstation defaults and so doesn't work.
If I then putty into the pi, and run the volume.py script manually - by that point in time - the emulationstation default (for me) has kicked in, so this new instance of the volume.py file then works correctly.

I've tried updating the volume.py file so that it is forced to use the Headphone audio device, but that doesn't work and complains about not finding that audio device.

I'm guessing that the assignment and even loading of the headphone output on the pi is being done after the rc.local has finished and may actually be after the emulationstation has also loaded entirely.

I think I need to find a way to move the lines I'm calling in the rc.local file into a file which is ran after emulation has finished loading.

do I have any options for that?

ByteThis

@mtm81 Thought I would recommend that sub as you don't seem to be getting many answers here. The folks over there have all kinds of mods to the cabs and many dedicated gurus that have knowledge of so called cabs.

Would be the second place I look since limited options here. Good luck !

mitu

EmulationStation doesn't change the audio output, it just uses one of them (HDMI/Headphone) - as configured. I think the issue with the script is not that ES needs to run before it.

What's the output of the script when it doesn't find the Headphone audio output ? You may try to add the script to the RetroPie autostart script in /opt/retropie/configs/all/autostart.sh, to be started right before EmulationStation is loaded.

mtm81

@mitu hi, thanks for the reply.

The script by default uses hdmi. It then looks for what it’s set to and changes itself to suit.
What I find odd is as follows.

when the script runs on startup it sets itself as hdmi (either because it doesn’t detect the actual or something else I’m not seeing). From then on it always sees it as hdmi. Even though the script it set to constantly check what the current device is set to, it always just sticks at hdmi
if however i putty into the device and run the script manually a second time , whilst emulationstation is running it then starts to work and correctly picks up the correctly set headphone value.
if I change the script so that I force it to use headphone as the value, I get an error that can’t find that device.

So in short, it will both only allow and/or use the headphone option AFTER emustation is loaded. Anytime during start it’s as if the headphone jack/setting doesn’t even exist!

It should be noted that I AM using the hdmi port on the pi as well but only for video output not audio

Does that help?

mitu

@mtm81 The script doesn't 'check' anything related to EmulationStation.
At startup it runs amixer scontrols and then it sets the mixer name based on what it detects, then it runs indefinitely without re-checking anything else again.

Looks to me that it uses the default audio card to retrieve the mixer name (otherwise it uses 'PCM'). You should try to set the default audio card in the Audio menu in RetroPie (not in EmulationStation) since that configures it for the entire system. See if the script works like this, otherwise I think the author of the script should know better.

mtm81

@mitu hi, I’ve already done that and the actual audio itself works fine.
It’s the fact that when the script runs as part of rc.local it detects the audio as being the hdmi whereas by the time the emu station has loaded that’s changed to headphone (which is the correct one)

Something definitely changes between the time it runs on rc.local and later in the boot sequence.

It’s as if the defaults of retro pie are being loaded after that script that ran..??

mitu

@mtm81 said in NEWBIE - help with volume.py not working..:

It’s as if the defaults of retro pie are being loaded after that script that ran..??

RetroPie doesn't load anything on start, except EmulationStation. EmulationStation itself doesn't change the system audio options, so I don't understand why the script doesn't work from /etc/rc.local - that's why I suggested you run it from RetroPie's autostart script, which loads EmulationStation.

mtm81

@mitu Thanks for the reply. So if I move my "sudo python /scriptlocationhere" line I've got in my rc.local over to the autostart file that should work? do I need to do anything other than that do you think?

mitu

@mtm81 It's worth a shot. The command should be

sudo python /scriptlocationhere 2>/dev/null &

Just add a line before the contains emulationstation.

mtm81

@mitu ok brill! I'll give that a shot and see if it makes any difference. I'll report back on here later!

mtm81

@mtm81 unfortunately that's no better.
The contents of the file are below.
If I run that from a startup script (rc.local or the autostart) , it detects the audio device as being HDMI (that could mean it's either not detecting anything or it is, at that point, picking up HDMI).

However I putty into the device and run the file manually, at that point - it gets the correct device as 'headphone' and then the switch works.

Any clues?

#!/usr/bin/python
import RPi.GPIO as GPIO
from time import sleep
from subprocess import call
from subprocess import check_output
import signal
import ConfigParser

config = ConfigParser.ConfigParser()
config.read("/home/pi/arcade1up/config/config.ini")
pinLow = config.getint('volume', 'pinLow')
pinHigh = config.getint('volume', 'pinHigh')

volLow = config.getint('volume', 'volLow')
volMid = config.getint('volume', 'volMid')
volHigh = config.getint('volume', 'volHigh')


def cleanup(sig, frame):
    global loop
    loop = False
    GPIO.cleanup(pinLow)
    GPIO.cleanup(pinHigh)

print("Starting " + __file__)

signal.signal(signal.SIGTERM, cleanup)

GPIO.setwarnings(False)
GPIO.setmode(GPIO.BOARD)
GPIO.setup(pinLow, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.setup(pinHigh, GPIO.IN, pull_up_down=GPIO.PUD_UP)

currentVolume = 0

device = 'PCM'

loop = True
while loop:
    pinMinState = GPIO.input(pinLow)
    pinMaxState = GPIO.input(pinHigh)

    controls = check_output(["amixer", "scontrols"])
    if 'Headphone' in controls:
        device = 'Headphone'
    elif 'HDMI' in controls:
        device = 'HDMI'
    elif 'Master' in controls:
        device = 'Master'

    print("Using device = " + device)

    newVolume = currentVolume

    if pinMinState == False and pinMaxState == True and currentVolume != volLow:
        newVolume = volLow
    elif pinMinState == True and pinMaxState == False and currentVolume != volHigh:
        newVolume = volHigh
    elif pinMinState == True and pinMaxState == True and currentVolume != volMid:
        newVolume = volMid

    if currentVolume != newVolume:
        call(["amixer", "set", device, str(newVolume) + "%"])
        currentVolume = newVolume
    sleep(1)

print("Finishing " + __file__)

mtm81

@mtm81 Thanks for the replies up to this point - I'm pleased to say that I've got it fixed (well kind of).

With my previous setup I've confirmed that the ALL of the default settings I was putting into the pi (alsamixer, retropi config, config.txt, autorun, even going so far in the config.txt to turn off the HDMI audio all together etc) to force it to use headphones - all were working but ONLY after a certain point in the boot sequence. Up to that point, because I had the HDMI plugged in (for video only) the system was detecting that HDMI connection and setting the ouput audio to be HDMI. Once one the files config files was THEN loaded, the Headphone output would then take over.
The issue was always that, my file which was being used to control the audio volume output of the device - was being loaded BEFORE those other files took over, meaning my file was effectively turning the volume up and down on an output I wasn't using.

I've therefore changed my output to HMDI for audio output as well, and changed my cabling from using the headphone jack on the PI, to the output jack on the HDMI controller.
This works absolutely fine and works first time.

So although this issue is solved, the underlying reason still remains - if you want to use the headphone output for audio - that only is 'forced' so far into the boot sequence.