... we're still alive!

[FBnil]

the analog audio does NOT get routed through the wheel

And the chip that does the volume (based on the dial) ... can not be reprogrammed in software? It's also the pop's I am worried about when you turn on the device, having it suspended while playing something. So when you turn it on, maybe the sound attenuator mis-reads, and suddenly the volume is maxed out.. (this nightmare is with those continual dials. I understand now that there is a maximum you can move it either way... a bit comforting). TBH, I was hoping for a analogue variable resistor (a classic volume dial).

Question: When moving this volume dial on the Pyra, does that information become visible on the taskbar's volume image? Or grabbable through ioctl(mixer_fd, MIXER_READ(SOUND_MIXER_VOLUME), &currentpyravolume)

Audio on the Pandora is also digital, before it goes into the DAC, or how did you think this works?

... uhmm... magical fairy dust? (I could be wrong, it could be just ordinary plain fairy dust, which also is electroconductive)

 

[Blue Shadow]

So the analog Volume Wheel of the Pyra is not even a analog volume Wheel?

Depends on the definition. It's an analogue wheel in the same way that an analogue joystick is an analogue joystick.

It's not an independant hardware volume control though (But I agree that's what some might expect).

 

[AnimatedFreak]

Didn't think there would be so much controversy over the volume wheel.

 

[rygD]

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?!

 

[levi]

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.

 

[rygD]

@levi I thought they were the same, thanks for clearing that up.

Here is a start for a list of games:
http://www.atariage.com/controller_page.html?SystemID=2600&ControllerID=2

 

[EvilDragon]

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.

 

[rygD]

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.

 

[Silent-Hunter]

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.

 

[Klumpen]

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.

 

[levi]

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?

 

[lukey]

Everything is controlled by Software to get the maximum flexebility AFAIK

 

[WizardStan]

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.

 

[Silent-Hunter]

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.

 

[Luke-Jr]

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.

 

[Xcl4m4t10n]

Button combination (Fn) to change wheel function. You can swap between master volume to brightness and in application function.

I just drop the idea ...

 

[bzar]

Is the volume wheel exposed as an evdev device in userspace?

 

[hns]

Is the volume wheel exposed as an evdev device in userspace?

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.

 

[Swordfish II]

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.

 

[EdenR]

But...i'm waiting for preorders....