Keep cool!


Ogers have layers.
You mean like this? :p
tumblr_static_tumblr_static_93dgecjusco4k0c00cssscs08_640.gif
 
Recently I bought some cheap stereo bluetooth headset to test if I could use something like it with the pyra.
I got it to play music from my laptop (using pulse).
But lost the interest to get the headset part working.

It somewhat unpractical at times to get it to work, requiring switching back and fourth between profiles until it accepts the correct profile, but besides that it works quite solidly if connected.

(I tried with xubuntu using blueman-manager and of course pulseaudio)

I had issues with my BT headset too until I figured out a sure way to get it to work:

Connect, then if it doesn't output audio I do these steps:
  • Go to Volume Control's Config panel and set Profile to "Off"
  • Disconnect BT headset
  • Reconnect BT headset
  • In the Config panel switch the Profile from "Off" back to what I want.
Then it works until I turn off the computer again.

Sometimes the audio falls way behind, I just switch it to "Off" and back to "High Fidelity Playback" and that clears the audio lag.

Took a frustrating while to figure out the exact steps.
Also I updated about two weeks ago and the headset has been working on the first try the 4 times I used them since. I don't know if its just luck or one of the updates fixed it. Time will tell.
 
Every time a thread goes to bike shedding makes it me happy inside. I know we're that much closer to having a baby pyra in our laps.
 
@rv6502-2 this helps but it would be cool if there was a way to automatically connect flawlessly (like my android phone does)
I originally thought that i could wear some sort of bluetooth headset, and if someone calls i could accept the call one the pyra an then use my headset.
Even if the update fixes the issue the battery of my headset only lasts for a few hours :( (some cheap 10€ headset)
I am interested how other people will use the Pyra as a phone, maybe i can adapt a good use pattern.

Everything is better than carrying two devices all the times. As soon as the pyra phone software gets at least somewhat stable and practical (even a terminal program is fine) i probably leave my phone at home.
 
I figure I'll use it mostly like a beeper (pager) from the 90's. Tell everyone to just text me, and if voice call is required text me their number and I will whip out the headset and call them.
 
@Pandora: I ditnt bother about the Bluetooth connection: i just use my little portable Bluetooth Transmitter, this way I also use cable less headphones on Switch and Gameboy..

But I hope it's much easier on Pyra whit Bluetooth..
Some news about the Case?? Because next week whe have August
 
I'm also worried about the bluetooth. And about the heat. And about the 4gb. And about the cases. And about the freezes... Well, actually I am thinking into cancel my pre-order :(.
 
Freezes? Could you elaborate?
@Xcl4m4t10n is worrying about a current issue when running the 4GB CPU boards. It's just literally finding the proper settings. With DRAM these things if they're wired properly tend to be one of two things timing or power, both can be controlled in software and currently the devs including someone from Ti is looking into it. This is something that can be fixed and currently being looked at, however everything is volunteer work by people that have full time jobs, so it's not like there is someone working on it 24x7 so we need to be patient.
 
The case was already fantastic when I held it for the keyboard test apart for the shoulder buttons, so I guess ED is fettling the thing while he's waiting for hardware bugs to be ironed out. I don't think any freezes have been identified provided you only use 2GB so the 4GB one is the only one remaining to be fixed.
 
I suspect he was referencing the other freezes - the ones that occur when trying to run the SoC faster than 1Ghz.

I thought those were going to get fixed by a new SoC board revision - but that was many months ago - I'm not sure if those changes have been implemented.

As far as I can tell, the devs are all working with units capped at 1Ghz with 2GB RAM - i.e. the 'old' version of the SoC boards that was populated long long ago.
 
As far as I can tell, the devs are all working with units capped at 1Ghz with 2GB RAM - i.e. the 'old' version of the SoC boards that was populated long long ago
From what I gathered there has been some 4GB board passed out to select devs.
 
I thought the >1ghz was solved thanks to that guy with the circuit analysis software, whoever it was, to make the power more stable or whatever. Or am I thinking of a different issue?

I recall that he helped to create a new spec for the SoC board, but I have not been able to find any references to where boards with those improvements were ever made.
 
I thought the >1ghz was solved thanks to that guy with the circuit analysis software, whoever it was, to make the power more stable or whatever. Or am I thinking of a different issue?
>1GHz was solved quite a while ago for existing developer prototypes by properly initializing the DRAM controller (EMIF). And the circuit analysis software has improved the PCB layout even more so that mass production Pyras should be more on the safe side (higher margins for noise). I regularly run my 2GB Pyra developer prototype at 1.7GHz and there are no clock speed related freezes. Only that it gets hot very quickly and may do an emergency shutdown. The 4GB Pyra is less stable (even at 1GHz) for still unknown reasons. Maybe just a similar DRAM controller setup bug (it uses different code than 2GB - see http://git.goldelico.com/?p=gta04-u...;hpb=be096ca0c2b204897b84c45e709511184b3a4059). Or something gets a hickup in the LPAE subsystem. But I was once able to successfully run 'memtester 3G'.
Unfortunately, such tests are time-consuming because they need a very controlled, repeatable and documented environment to pinpoint the root cause.
 
That's probably because you didn't understand the problem with it. I do like it myself - as the simple startup service concept it originally wanted to be. But that's not what systemd is today, that's just one tiny little bit of it. The big issue is the crapload of useless things added ontop of it, in addition to Poettering's legendary mindset towards issues that are not supposed to exist.
(Sorry to restart the systemd discussion) While Poettering have a broken mindset, Debian is serious about security. All the known CVE are fixed by debian patches, like this one.
Full list here. If there's anything missing in this list, open a debian bug, the security team will do its job.

EDIT: and that's an other reason to prefer debian over ubuntu (they fork SID where debian security doesnt work)
 
Last edited:
EDIT: and that's an other reason to prefer debian over ubuntu (they fork SID where debian security doesnt work)
That's not true at all. They manager their own security patches. See https://usn.ubuntu.com/usn/usn-3341-1/ for your example.
Debian is often faster, but compare https://wiki.debian.org/LTS to https://www.ubuntu.com/info/release-end-of-life for security update lifetime (plus debian LTS is not as good/fast as debian security).
And note that ubuntu non-lts updates packages to latest twice a year, but they officially do support it. SID is not intended for production use, ubuntu is.
I personally prefer arch over debian over ubuntu, but there are many cases where ubuntu is the better choice, even though they bloat their system with crap.
 
Back
Top