Pi install

From: CHYRON (DSMITHHFX)23 Aug 2018 16:26
To: graphitone 34 of 92
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
From: Peter (BOUGHTONP)23 Aug 2018 20:58
To: graphitone 35 of 92
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?

From: graphitone23 Aug 2018 21:16
To: Peter (BOUGHTONP) 36 of 92
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.

 
From: Peter (BOUGHTONP)23 Aug 2018 21:30
To: graphitone 37 of 92
> 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.

From: Peter (BOUGHTONP)23 Aug 2018 21:52
To: graphitone 38 of 92
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.

From: ANT_THOMAS23 Aug 2018 22:17
To: Peter (BOUGHTONP) 39 of 92
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.
From: Peter (BOUGHTONP)23 Aug 2018 22:50
To: ANT_THOMAS 40 of 92
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/

From: graphitone23 Aug 2018 22:52
To: Peter (BOUGHTONP) 41 of 92
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.
From: graphitone25 Aug 2018 08:57
To: ALL42 of 92
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.
From: graphitone25 Aug 2018 15:16
To: All 43 of 92
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.
 
Code: 

#!/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.

 
EDITED: 25 Aug 2018 22:13 by GRAPHITONE
From: Peter (BOUGHTONP)26 Aug 2018 15:12
To: graphitone 44 of 92
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?

From: graphitone26 Aug 2018 19:41
To: Peter (BOUGHTONP) 45 of 92
Yeah, they do. The DAC covers all 40 pins, while the amp takes the first ten and passes them through to the headers on top of the whole stack. I'm pretty sure it's passing  pins 1 - 10 through as shorting 5 and 6 with the script configured to use them did shut it down. I don't get that if /a/ GPIO pin can be utilised to do a thing, then why couldn't /another/ GPIO be used to do the same thing, providing it's (apparently) unused?
From: Peter (BOUGHTONP)26 Aug 2018 21:44
To: graphitone 46 of 92
Well yeah, if GPIO is supposed to be general purpose then any unused pin should work.

It seems counter to the point of this to take all pins, only use some, and pass through ones that can't be properly used. What about sending a message to IQaudio seeing if they're willing to help?

Failing that, maybe you can de-solder the connector and replace it with several smaller ones, including a right-angle connector for the unused ports? Or I guess cables would be easier at the expense of compactness.

From: graphitone26 Aug 2018 21:55
To: Peter (BOUGHTONP) 47 of 92
That's a fair idea, I'll send them a message. There must also be some kind of inbuilt shutdown script, as there's a software power button within the Kodi interface. If I can find that, I might be able to add in the backlight commands, which would be half the battle won.
From: Peter (BOUGHTONP)26 Aug 2018 22:19
To: graphitone 48 of 92
> There must also be some kind of inbuilt shutdown script

Heh, so yeah, that's a really simple solution - that loser Xen would have pointed it out ages ago if he were here.

You can use systemd to hook into system events (like shutdown), so you can create simple service like this one with Before=shutdown.target:

[Unit]
Description=/etc/rc.local.shutdown Compatibility
Before=shutdown.target

[Service]
ExecStart=/bin/true
ExecStop=/etc/rc.local.shutdown
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Where /etc/rc.local.shutdown is a script containing the original echo 0 > /sys/class/backlight/rpi_backlight/bl_power (prepended with #!/bin/bash line) and once you've enabled that service, any time the system is shutdown - whether via Kodi or command line or the button - it triggers the script and turns off the backlight.

From: graphitone26 Aug 2018 22:19
To: All Peter (BOUGHTONP) 49 of 92
Okaaaaay... I've created a shutdown file here:
 
Code: 
/storage/.config/shutdown.sh

And created this script, putting in the backlight command under the poweroff option.
 
Code: 
case "$1" in
  halt)
    # your commands here
    ;;
  poweroff)
    # your commands here
    ;;
  reboot)
    # your commands here
    ;;
  *)
    # your commands here
    ;;
esac

This works with the software power off, but will mean I need to flick the power switch (which'll be mounted in an under counter cupboard) to get it to turn back on. So, not ideal, but it'll work for now. :)
EDITED: 26 Aug 2018 22:20 by GRAPHITONE
From: ANT_THOMAS26 Aug 2018 22:21
To: graphitone 50 of 92
If I'm understanding what you want to do there is a pin available on the RPi to reset the board/power. Connect a button, press it, and it'll act a soft on type button by resetting the RPi from its shutdown state.
From: graphitone26 Aug 2018 22:23
To: ANT_THOMAS 51 of 92
Ah, that'd be damned useful, providing it's somewhere between 1 & 10 and isn't 5!
From: ANT_THOMAS26 Aug 2018 22:24
To: graphitone 52 of 92
It's totally separate. It's called "run". Different location on different versions of raspberry pis but the newer ones have it.
From: graphitone26 Aug 2018 22:27
To: ANT_THOMAS 53 of 92
Found this which seems useful, I'll have a read before bed:

https://www.raspberrypi.org/forums/viewtopic.php?t=218600