NEWBIE - help with volume.py not working..
-
@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?
-
@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 !
-
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. -
@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?
-
@mtm81 The script doesn't 'check' anything related to EmulationStation.
At startup it runsamixer 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.
-
@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..??
-
@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. -
@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?
-
@mtm81 It's worth a shot. The command should be
sudo python /scriptlocationhere 2>/dev/null &
Just add a line before the contains
emulationstation
. -
@mitu ok brill! I'll give that a shot and see if it makes any difference. I'll report back on here later!
-
@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 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.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.