**** BEGIN LOGGING AT Tue Sep 13 02:59:57 2022 Sep 13 04:21:44 everything works but there is an issue where when the audio plays on the speakers the beginning is cut off and the end is cut off Sep 13 04:22:21 is it due to the buffering, delay or a lack of a certain component in my command? Sep 13 04:26:48 hi Sep 13 04:26:51 anyone here ? Sep 13 17:02:04 hello Sep 13 17:02:13 hope everyone is having a great day Sep 13 17:04:03 I have an inquiry regarding the playback of the songs from MPC and its issue with cutting audio from the beginning and pausing/ending the song before it actually concludes. Is there a limit that i have to adjust or is it just a consequence of buffering? Sep 13 17:07:06 the song is three minutes long Sep 13 17:07:35 so i assumed it wouldn't be an issue Sep 13 18:59:43 I've been playing with the gpios with a relay attached to one.  I notice that when I set the direction to out ('echo out > direction' for any gpio under /sys/class/gpio/gpioXX) it seems to immediately turn the gpio on (is that considered high?).  The value is 0, and if I change that to 1 it is turning the relay off.  IOW, it seems backwards. Sep 13 18:59:44 Is that expected?  Or does it suggest I have something wired backwards? Sep 13 19:36:11 Guest4494: 1. when changing a gpio to output you should write the initial level, either "low" or "high" to the direction attribute... writing "out" is a synonym to writing "low" Sep 13 19:36:49 and depending on how you wired up your relay it's entirely possible for it to be turned on when the gpio is low Sep 13 19:37:34 I have an inquiry regarding the playback of the songs from MPC and its issue with cutting audio from the beginning and pausing/ending the song before it actually concludes. Is there a limit that i have to adjust or is it just a consequence of buffering? Sep 13 19:39:01 Guest4494: there's actually an "active_low" attribute you can set to 1 to invert the meaning of the value attribute for such situations, i.e. when active_low=1 then value=0 will correspond to a high level of the gpio and value=1 will correspond to a low level of the gpio Sep 13 19:39:57 DoubleA: my guess would be it just has to do with how pulseaudio-dlna works Sep 13 19:41:00 could there be a limit in the configuration file perhaps? Sep 13 19:43:54 zmatt, active_low seems to be the key.  I wonder if that was created because such situations would seem to be confusing.  In my case, setting the direction to low/out immediately causes the normally-open side of the relay to close.  Setting active_low = 1 appears to prevent this, as you said.  Thanks. Sep 13 19:44:25 DoubleA: it's possible there are options that can be tweaked to influence this, but some of the buffering is likely to be in the clients (your google home speakers) Sep 13 19:44:47 I do wonder why active_low is necessary.  Is that ultimately a kernel behavior? Sep 13 19:45:00 Guest4494: it just depends on your hardware setup Sep 13 19:47:58 e.g. in your case, whether your relay is active when the gpio is high or when the gpio is low depends on the details of how you hooked up that relay... similarly in other situation it may vary which gpio level is the "active" level Sep 13 19:48:37 the kernel has no way to know this obviously unless you explicitly tell it, which you can do via the active_low attribute Sep 13 19:49:54 DoubleA: maybe there's a way to force mpd or pulseaudio-dlna to keep streaming audio (silence) even when mpd isn't playing anything Sep 13 19:50:26 that won't get rid of the delay, but at least it'll avoid any audio getting cut off at the start/end when mpd starts or stops playback Sep 13 19:52:45 it's also not encouraging that pulseaudio-dlna appears to be unmaintained since 2017 Sep 13 22:35:57 i did lots of research regarding forcing mpd/pulse audio to keep streaming audio but unfortunately i found lots of forums taking about another server client Sep 13 22:36:15 rythmbox to be percise Sep 13 22:37:12 zmatt do you happen to know what command can be used to perform the task of forcing the player to keep playing? Sep 13 22:46:20 i searched the list of commands and it seems vague Sep 13 22:47:26 play Sep 13 22:49:08 nothing else comes close Sep 13 22:49:20 consume perhaps? Sep 14 00:55:28 hello can I get a solidworks prt file for the beaglebone black Sep 14 02:24:03 Guys! Never fear me. Dang it. Sep 14 02:25:09 I have an idea. Make something. That is the idea. Is it okay if I use a Cape w/out EEPROM? Sep 14 02:25:56 I know most people would advise against set_, me, using Capes w/out EEPROM and building them. Sep 14 02:27:59 The Capes people make are awesome. Do not discredit my knowledge of how nice the current Capes are currently. Sep 14 02:28:20 I just thought making one would be a step up in learning. Sep 14 02:28:33 Not... Sep 14 02:28:45 1. A Breadbaord Sep 14 02:29:11 2. another circuit... Sep 14 02:29:30 3. and not a "cool" thing. Sep 14 02:30:19 I really wanted to try to make it. I am learning slowly (very). And! I know nothing about what the beagleboard.org persons are doing w/ Capes currently or in the future. Sep 14 02:30:50 So, I figured, I could learn a bit, produce, and try things out... Sep 14 02:38:42 i read the info. about the Cape production on the BBB Rev. C wiki. I know the "rules." Supposedly. Sep 14 02:39:07 I mean...is an EEPROM necessary on the Capes for self use or only in production instances? Sep 14 02:43:19 side note...PyTorch is now a Linux based "thing-a-ma-doodle." Neat! More! **** ENDING LOGGING AT Wed Sep 14 02:59:56 2022