... we're still alive!


I have also had the problem of Android devices making sounds at inconvenient times, or sometimes crashing and sound not stopping (or maybe that was a computer). What I really want to hear more about is using it in games.

I am trying to remember how paddles work. I only used them rarely as a kid, and unfortunately I don't currently own any even for my consoles and such that can use them. Weren't they continuous in their spinning? I thought they were analog, so how did that work? Can I play Pong and other games correctly with the volume control pot? Are there any emulators that could easily (mis)use this method of input without much effort by users, or will we need a Pyra Edition of them? What other games would you all want to play in this way?

3D!7: How could I forget Breakout?!
 
Last edited:
By my definition, a games paddle has stops whch correspond to the top and bottom or the screen or its sides, and a spinner doesn't.

I've had my computer make repetitive loud noises as a result of a crash not refilling some buffer somewhere, but that was a program crashing, not my sound system, and it's always been possible for me to mute the sound. In the worst case I can always shut down, and if that fails to work, pull the battery, but so far I've never needed to for audio issues.
 
I've never had issues with any Android phone. If the sound is off, it's off. No crash has ever changed that.

ALSA/Pulseaudio restores the audio on startup, and instead of restoring the last saved setting, it'll read out the position of the volume wheel.
That's one of the simplest things to do.
 
The problem as it exists with Android was described earlier. If you have have some volumes set for a certain level, but not others, you can be in for a surprise. For example, turning sound down while playing a game or watching a video while notification sounds are still maxed out. Message/call comes in and plays sound very loud. I don't usually mute, instead lowering volume to an appropriate level for my surroundings. I don't think it would be a problem with Pyra, but we shall see.
 
The Pyra could always be set to have only one master volume, so whatever you're currently doing you can ALWAYS just change the wheel and it'll affect everything at once.
 
I guess that's really just a software thing and you guys wouldn't want to compare Pyra's Debian to Android, or do you?
Of course, direct control of the soundchip's audio out would be great, I wonder why it's not possible.
 
The Pyra could always be set to have only one master volume, so whatever you're currently doing you can ALWAYS just change the wheel and it'll affect everything at once.
I guess this is something that might need to be configurable - some might prefer the certainty that modifying the master control using the volume wheel might give, while others will want to use their Pyra as an alarm clock regardless of the volume they were last listening to music at.

Out of interest, how will the Pyra handle headphones? Will having them plugged in cut off the speakers, or will it be handled by software as well, so that an alarm app could still ring the speakers even if headphones were plugged in?
 
My problem with having only a master volume is that my headphones are very loud for some reason. I keep my software volume at around 10% so that my wheel can have a full range of control. If it only controls master volume, my use case limits me to a few mm span on the wheel.
But everything being in software means that a solution can be coded, so it's not a really big deal.
 
Well I wouldn't suggest it be permanently locked to it. Just the default. And you could likely set a curve of some sort as well.
 
Sounds like ideally, there should be a separate volume for Master, Speakers, and Headphones. Master affects both and is controlled by the wheel, whereas the latter two affect only the individual ports and can be left fixed to some reasonable value.

To have alarms use a different volume than music sounds like some major ALSA configuration complexity, though.
 
Is the volume wheel exposed as an evdev device in userspace? :oops:
It is exposed as an iio channel and a /sys file (Palmas GPADC) reporting values between 0 and 1200. Wrapping iio with an evdev kernel driver appears to be doable. It could for example emit VOLUMEUP, VOLUMEDOWN and MUTE key codes...
A simple volume-daemon that works well enough for testing is here: http://git.goldelico.com/?p=gta04-k...f;hb=9da7ed16489d0fba652ad7f1a0ff415621e5269d
There is still the hardware option to use it as a real analog attenuation device for the separate DAC + amplifier (like Pandora).
But we have not yet tested that any of the prototypes. It needs hardware changes and someone to write appropriate sound driver code. So we simply do not know if and how good it can work.
 
Last edited:
The problem as it exists with Android was described earlier. If you have have some volumes set for a certain level, but not others, you can be in for a surprise. For example, turning sound down while playing a game or watching a video while notification sounds are still maxed out. Message/call comes in and plays sound very loud. I don't usually mute, instead lowering volume to an appropriate level for my surroundings. I don't think it would be a problem with Pyra, but we shall see.

Or you could use the global silent or vibrate function, Never had it make a noise after that is set. The problem you describe is a user being surprised by settings that they themselves set.
 
There is still the hardware option to use it as a real analog attenuation device for the separate DAC + amplifier (like Pandora).
But we have not yet tested that any of the prototypes. It needs hardware changes and someone to write appropriate sound driver code. So we simply do not know if and how good it can work.
If hardware changes are on the table, I'd much rather see one that can turn infinitely in both directions and only report the change rather than an absolute value.
Using absolute values has one minor benefit (surviving an unexpected reboot without committing every change to flash), whereas relative values enable a lot more functionality (dual purpose for brightness, application-specific vs global volume, etc) and avoids other more common problems (not being able to have alarms loud despite whatever the desired application-volume is).
 
Or you could use the global silent or vibrate function, Never had it make a noise after that is set. The problem you describe is a user being surprised by settings that they themselves set.
Obviously it is the user that changed the volume, but it isn't really as simple as you make it sound. Perhaps it depends on the version of Android and manufacturer changes. I am describing a situation where someone went from max for the main volume (when they left home, or were in a loud public place), then they start a game and push the volume buttons to adjust it, such as lowering it to avoid disturbing others. While still playing the game a message comes in and the notification is played at full volume. I can check a few Android devices to see if this would happen with all of them. I don't recall what happens if you have the master volume muted then turn up the volume while in the game (however this wouldn't work for me since I need to know when someone is trying to reach me, and my vibrator motors are pretty much dead in my main ones).

Again, I don't see this being a problem with the Pyra. As long as there is a way to have alarms play full volume, or turn sound to max remotely when it is misplaced, I will have more than I expect/need. It will be nice to have vibrate again, and the big indicator logo should help if that dies.

I would prefer this not descend into another "you never need more than 3 browser tabs" vs "I usually have 1000 tabs open" type of pointless debate. People use their things differently.


But...i'm waiting for preorders....
Right? I am waiting for the email saying I need to pay the rest so it can be shipped.


If hardware changes are on the table, I'd much rather see one that can turn infinitely in both directions and only report the change rather than an absolute value.
Using absolute values has one minor benefit (surviving an unexpected reboot without committing every change to flash), whereas relative values enable a lot more functionality (dual purpose for brightness, application-specific vs global volume, etc) and avoids other more common problems (not being able to have alarms loud despite whatever the desired application-volume is).
Not as the default configuration, please. Are you really going to be adjusting screen or keyboard brightness with the thing closed? You can adjust those using keys, and that key is in an easy to find location (in case everything is off). You should be able to change individual volumes in software (maybe), and the alarm thing shouldn't really be that difficult (I can think of a rather simple way to do this that is built into Linux, but I would need to actually test how difficult it is to set up...maybe a GUI tool can be thrown together to make it even simpler).
 
Back
Top