What you doing taking pictures of Throb's living room?

"Somehow I've lost all sound"

My sound broke in Arch by doing something that buggered around with PulseAudio, which then fucked up ALSA, because PulseAudio is a buggy bloated piece of shit that nobody actually needs.

So maybe you installed/upgraded (possibly automatically) something that did fiddled with PA?

You're still using the "Are we there yet? Are we there yet? ..." method instead of the "Tell me when we're there" one.

If you do really want to do it this way, since you only care about shutdown, you don't need to store/check oldButtonState and can simplify it to:

GPIO.setup(5, GPIO.IN, pull_up_down = GPIO.PUD_UP)

# endless loop until button is pressed
while GPIO.input(5):
	time.sleep(.1)

# verify button state before switching off
if not GPIO.input(5):
	subprocess.call("echo 1 > /sys/class/backlight/rpi_backlight/bl_power && shutdown -h now",
		shell=True,stdout=subprocess.PIPE, stderr=subprocess.PIPE)

The if verification is probably not necessary (depending on how Python works), but even so it acts as both a safety against unwanted shutdown (incase something goes wrong), and clarifies the intent slightly. (The event-driven/callback method would make it even clearer.)

:D

Has he really got a 70s stereo system?

Could well be.

IQaudIO produce this document (a pdf download) which seems to be wrriten in multiple styles and changes between being helpful and downright confusing.

I'll check the onboard audio is properly disabled and might go back to a vanilla image, and test the sound after every change made.

 

Other than being more optimised (and I appreciate the arguments for non-bloated code) does that have a knock on effect on real world performance or not?

Thanks for the suggestions though, I'll try that once I get the sound working again!.

 

"changes between being helpful and downright confusing"

So standard documentation.

(nod)

Pretty much. There's an indepth walkthrough of how to build a case with diagrams, then when it comes to installing a rotary encoder as a volume knob it's referencing external libraries and assumes ones knows how to call seperate processes as part of the code.

As a linux luddite, I'm able to fumble my way through most of it with online guides and PB's assistance, but it's not something I use everyday, so whatever I learn soon leaves my brain to be replaced with ingratiating one line lyrics from songs that seem to be on a permanent repeat. 

I think many/most engineers who write their own documentation fail to appreciate the ambiguities of language, and assume users will be able to infer WTF they are talking about, and if they can't, tough shit you lose. I suppose we should be grateful even for that.  :C

How does a sound card require 48 pages of documentation? :/

And what's wrong with the onboard sound that made you opt for this route?

The onboard sound is crap. I've got a DAC setup on another Pi attached to my drawing desk and it really makes a difference, the audio is clean and sounds brilliant, way way better than the awful quality through the 3.5mm jack on the Pi.

 

> does that have a knock on effect on real world performance or not?

Dunno - it has the potential to, but I suspect one instance isn't going to have much impact - but if you do get symptoms of the CPU being congested (e.g. stuttering audio or sluggish response), I'd check that first.

Is that music-snob awful or actually bad? :/

The cards in that documentation look chunky - presumably mixing Pi extension cards can quickly give rise to compatibility/connectivity issues.

Actually bad.
There's a vast difference even when you use a 99p USB DAC compared to on board. I think on board has improved since the first gen Pis but still not great due to the design restrictions.
There's an even bigger improvement if you use the I2S DACs. Not checked the one graphitone is using but there's some nice models out there that also incorporate an amplifier into the DAC HAT.

Makes sense, but was frustrating me thinking about having lots of cards/wires and extra complexity.

But it's been a long day and I only just remembered that my plan was to go via MDI connection, so the audio on the Pi is irrelevant. \o/

What Ant said, the onboard gives out random pops and hisses when listening to anything.
My DAC is an I2S and sounds great with a decent pair of headphones (on the drawing desk one). I've got that hooked up to a switch that alternates between the headphones and a pair of PC style speakers, so I can put the sound through them too.

The only difference with this setup is that I've got the amp addon (from the same company, so you'd assume they're compatible). I've just found some, admittedly old, builds on IQaudIO's website that are preconfigured. The kodi one was totally out of date and wouldn't run on my Pi3, but there's a Volumio build which I'm downloading now. I'm not tied to Kodi, just that I'm more familiar with it, and Volumio has an option for a Kodi plugin.

The pre-configured builds hosted on IQaudIO's site are either too old for the most recent Pi3, or are corrupted in some way, 'cos they don't run :C

Back to the backup plan of using a backup of Kodi on LibreElec and seeing at what point the sound buggers up.

I found that the issue with the sound not working happens when the shutdown script is invoked.

I'm just running the script manaully and not committing it to the autostart.sh and it turns the sound off.

I'm going with the vanilla script again, and providing I can get this working, I'll go with PB's other suggestions.
 

#!/usr/bin/python
import sys
sys.path.append('/storage/.kodi/addons/virtual.rpi-tools/lib')
import RPi.GPIO as GPIO
import time
import subprocess

# we will use the pin numbering to match the pins on the Pi, instead of the
# GPIO pin outs (makes it easier to keep track of things)

GPIO.setmode(GPIO.BOARD)  

# use the same pin that is used for the reset button (one button to rule them all!)
GPIO.setup(5, GPIO.IN, pull_up_down = GPIO.PUD_UP)  

oldButtonState1 = True

while True:
    #grab the current button state
    buttonState1 = GPIO.input(5)

  # check to see if button has been pushed
  if buttonState1 != oldButtonState1 and buttonState1 == False:
    subprocess.call("echo 1 > /sys/class/backlight/rpi_backlight/bl_power && shutdown -h now", shell=True,
            stdout=subprocess.PIPE, stderr=subprocess.PIPE)
    oldButtonState1 = buttonState1

    time.sleep(.1)

Going through the manual again, there's a section of what's passed through the GPIO.
The DAC uses pin 5 for I2C.  I reckon if I'm now scripting that 5 is something else, that's what's kicking the sound out of touch. On that diagram though GPIO5 is pin 29, so as the script mentions it must be using the physical layout as only the first 10 pins are presented on top the Amp card and when the script runs, the power button works, but has the undesirable sound side effect.

So, with the attached diagram(s) in mind I'm guessing I could swap pins 5 (gpio3) and 6 (gnd) to be 9 (gnd) and 10 (gpio15). Would that be feasable?!

UPDATE - I've tried a combination of the other pins and updated the script accordingly. No joy there.

The pin diagram from the manual shows 7, 8 and 10 are available pins and I've tried them all against a pin 9 ground and it's just not doing anything when the shutdown button's pushed. I read that pins 5 and 6 are somehow favoured for the two pins that when shorted will put the Pi into a sleep mode. I haven't yet found whether this can be changed.

 

The GPIO.setmode(GPIO.BOARD) makes it use pin numbers, but you can use GPIO.setmode(GPIO.BCM) to use GPIO numbers instead.

The DAC/AMP might only provide the first 10 pins on top, but it's not clear from photos if they actually prevent you connecting to the other pins underneath?