So, what's the current status of everything?


I'm so excited! There's a chance we will all get our Pyras before the end of the decade!
I'd hope so, since there's still a year until that happens (if you believe that we really started counting at year 1 AD)

Edit: I really should learn better at noticing that 'there's another page' notice (or whatever it says) at the end.
 
I'd hope so, since there's still a year until that happens (if you believe that we really started counting at year 1 AD)
You at risk of confusing offsets with numbers, which seems to be an oft-occuring problem amongst programmers? ;)
 
Are you sure? If the decades run contiguous from the start, they would begin at the start of 1 CE and run to the end of 10CE, making ten whole years. So the next would be 11CE to 20CE, and the current one would be Jan 2011 to Dec 2020.

Of course, they're a more recent invention as far as I know, so nobody's actually saying they need to run contiguously from the start, unlike the centuries. I'd be perfectly willing to accept that the third digit is more important than any derivation, but my comment was intended to be flippant and something of a joke, so being slightly ridiculous is permitted.
 
Yeah, but that's not ED's concern at the moment. It's a side project of HNS only for now at least, and he's waiting for phone software development and testing on the Pyra itself first mainly at present I think.
ik ok
 
Haven't had a new update in a while.
Then you should have a look at
I think after page 21, there are the first pictures and small reviews for the shipped prototypes.
 
Are you sure? If the decades run contiguous from the start, they would begin at the start of 1 CE and run to the end of 10CE, making ten whole years. So the next would be 11CE to 20CE, and the current one would be Jan 2011 to Dec 2020.
The latter I'd call the second decade of this century. The 20-10s I'd call the years matching /201[0-9]/. But that's just me. I don't know what the norm says. And I don't remember what my point was writing my last comment. :)
 
Looks like sndio may be a way to have a clean audio:
One of the main reasons PulseAudio is being used is the ability to configure Bluetooth audio devices on the fly, if it doesn't support that we could just as well go back to full ALSA.
 
Why shouldn't it be possible ?
 
  • Like
Reactions: rSl
Plus I'll note I don't have any of the issues listed on that link. My audio hardware does sometimes crap out and it takes a second to reconnect which usually hits once or twice per album but I recall it does similar using ALSA, and it certainly never does any of the bullshit they talk about there. I can see reasons to distrust pulseaudio, most of them beginning with some slight against the sayer by a certain LP, but lying about the project I'm using to make me use another doesn't work for me.
 
Why shouldn't it be possible ?
Seem to be a lot of fiddling around for the end user.
It looks like you need to choose the alsa audio device each time you want to play audio to speaker / headphone / bluetooth.
With Pulseaudio, you can redirect the stream on-the-fly, which is a huge advantage.
 
Seem to be a lot of fiddling around for the end user.
It looks like you need to choose the alsa audio device each time you want to play audio to speaker / headphone / bluetooth.
With Pulseaudio, you can redirect the stream on-the-fly, which is a huge advantage.
Seems only a user-space tweaking, at least it's worth investigating.
Post automatically merged:

I think some of us are trying to avoid pulse and friends.
We have to keep opensource open, and free software free.
 
Seems only a user-space tweaking, at least it's worth investigating.
It does not provide any sort of dynamic configuration. You can't just change environment variables of programs that are already running and changes to ALSA's configuration files requires restarting all applications that are using it. I wouldn't be surprise if losing connection to the Bluetooth device would break audio entirely just because the sound device becomes unavailable, ALSA just isn't designed to handle these kind of things.
 
Yes, I don't think dynamically switching around audio streams will work with ALSA.
To my knowledge, you have to stop and restart the stream to switch the output device,

And you have to do that in the program, ALSA itself can't do that... which is the reason I think there's no real way around pulse.
 
Back
Top