... we're still alive!

[Majin Wamu]

So....Beautiful!

 

[rSl]

a usecase for a pretty well known audio-volume status would be when using sensitive deep canal iem's.
you really want to avoid loud pops when using these, or your ears are going to say **ouch**.

regarding the audio circuit,
is there still enough time for testing this if hardware/software changes are needed?
maybe it's better to skip the tests and remove this hw and save some time/bucks we spent on the larger nand?
i really would like to have the burr-brown dac/true analog volume control and (maybe) better soundquality, but
is it 'worth' the delay for testing and the higher price for the added chips and caps?
also it would add development time for the kernel-driver.
hmmm.... the joy of decisions!

 

[Swordfish II]

@rygD

There is just so much nitpicking going on. Poor ED he is just concentrating on getting the thing out, and enterprising people on here will post a variety of scripts, .dbp's and apps to take care of most use cases I am sure.

IMO now is the time to sit back, trust, and let the poor project launch

 

[rygD]

That was my point, too. Let the man make them and get them out, then we can worry about it not being enough like an Android smartphone/tablet . He seems to be happy with the audio stuff as it is, so if that is what we are getting let's not ask him to spend more time and money (and I WOULD prefer to have the potentiometer directly control sound, however the benefits of having it the other way are there too, like using it for games, and not making you miss an alarm because you forgot to spin it to the right).

If it is something ED still plans to test in the prototype run, sure, continue on discussing it. I don't think I can say the way he has it now will be bad until I use it and something goes very wrong. I would like to protect my sensitive earballs from random assaults when changing the volume.

 

[EvilDragon]

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.

No, you wouldn't. Those wheels are horrible.
They got about 15 steps per 360° turn, so to have a proper volume (where you don't here the stepping), you'd need to make the steps so small that you need to turn it 10 - 15 times fully to go from lowest to highest setting.
Or you'd have steps.
Or need to use a modificator key to increase the step size.

We looked, there's nothing really feasable.

regarding the audio circuit,
is there still enough time for testing this if hardware/software changes are needed?

What change?
The volume wheel works fine, that's the hardware test.
The software side will be reading out the set volume and reporting it to the audio driver.
Nothing spectacular.

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

I still need some last details to be solved (how much i have to pay in advance for the production runs, some final prices of some parts, etc.) and I also need to check with PayPal whether they're okay with such a huge preorder and how to handle that.

I will post a more detailed update later, but we're getting there.

 

[Djoga'Ro]

@Swordfish II Whenever something still discussed cannot be changed easily anymore, ED might state that and maybe why, and the particular discussion would fade out with the occassional would-have-been-nices.
Everything else you might consider polishing or fine-tuning.

Edit: Ah see, there he is.

 

[rSl]

What change?
The volume wheel works fine, that's the hardware test.
The software side will be reading out the set volume and reporting it to the audio driver.

i meant the amount of work to get the burr-brown circuit in a working state for comparing against the soc-audio solution.

 

[_wb_]

An analog volume wheel with software control is the best of both worlds, if you ask me. Obviously the low-level software has to be reliable, but I don't see why that would be harder to do than e.g. making the keyboard or nubs reliably do what they're supposed to do.

Software control means you can potentially configure everything, and override it too if needed: e.g. you could write something to wake you up in the morning that works even if you dialed down the volume the night before.

 

[oskda]

Well it's still a regular potentiometer connected to an ADC. There technically is a limit to the min and max hardware wise, since there is only so much of a range due to the analog voltages fed to the ADC, but software wise the granularity could be adjusted.

What digital resolution has ADC connected to wheell? 8 bits? 16 bits? (with 256 or 65536 steps/resolution we have enough, I suppose ).

Really I think your solution it is pretty cool, and better than a direct potentiometer controlling sound volume (or a digital wheel with only a few positions). With this solution we get best of both worlds (for example fine and rapid volume setup and at the same time mute button and other soft options to control volume).

 

[Binky]

Seriously, how often has the Pandora crashed on any of you continously playing an annoying sound where you needed to use the volume wheel to turn it down?
I'm asking about a FULL crash, not a program crash, as the audio daemon will still work when a game crashes.

I've had a few userland applications (flash, and possibly fluidsynth, I think) crash on my debian desktop in such a way that they eat all the memory and CPU time available to them, leaving some hardware buffer to stut stu stut stutter over the same audio segment while everything else locks up.

OOM intervenes eventually, of course, and its sufficiently rare that I probably wouldn't worry that much about it.

If applications themselves are allowed to manage the volume, that could be a genuine problem (either due to bugs, or users not understanding the intended behaviour)
If the demon monitoring the volume wheel crashes, its quite possible that the whole system has come down too, and theres nothing left to play sound anyway..

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).

I disagree.
Most rotary encoders don't really have fine enough precision for this sort of thing (I've seen 24-step ones)
A potentiometer with hard limits alllows you to set the volume without an on-screen display and before sound actually starts playing.
If an alarm demon was given special volume-setting privs, it could override the volume wheel while playing alarms, then return it to a more sensible level

 

[oskda]

So this should be digital then? Analog volume wheels have audio going through them right?

Really wheel is ANALOG, you command it in ANALOG WAY, but it is converted to digital (I have asked ADC resolution; I suppose it will be at least 8 or 16 bits) as digital computers don't compute analog quantities but digital ones.

It is an analog wheel, but it isn't controlling sound power directly, but by soft.

A digital wheel has a few positions fixed: sometimes there is only 1/2 sensors and they sense if you turn it right or left a position at a time. This is not that way, but an analog wheel wich position/output is digitalized.

With 8 bits ADC connected to wheel we have 256 positions... I suppose it is enough, but if ADC is 16 bits, we have 65536 positions for that wheel after "position digitalization". In a phone/autoradio with digital wheel (or digital button) usually we have only about 8 or 10 or 16 positions/values, so this feels like abrupt steps, but with 256 or with 65536 (2^16) in Pyra wheel we have something near lineal, with very soft steps but with rapid control (it is impossible to do the same, that resolution and rapid control on a digital wheel).

Really I love the idea behind this analog wheel connected to ADC. It has the best of both worlds and a lot of other possible uses.

PD: Offtopic: Where do "?MEMORY OVERFLOW ERROR. / READY" came from? In C64 I know about "OUT OF MEMORY ERROR" and "OVERFLOW ERROR" but no about "MEMORY OVERFLOW ERROR"

 

[WizardStan]

What digital resolution has ADC connected to wheell?

I think it was mentioned that it was 1024 steps, so 10 bit resolution. That's pretty standard, a lot of ADCs use that level of resolution by default.

 

[oskda]

I think it was mentioned that it was 1024 steps, so 10 bit resolution. That's pretty standard, a lot of ADCs use that level of resolution by default.

More than enough I think

How many levels has the output level register in Pyra sound chip? (is it in OMAP or is it a external chip?)
[doublepost=1460296319,1460295609][/doublepost]

Exactly this! With phones it happened to me a couple of times that I had to muffle the entire device in my sweater because it suddenly started making noise at very inconvenient times (I work in a very quiet concert hall) because the volume control didn't work. This could be either noisy advertisement banners, alarms, incoming calls or text messages etc. It's only fair to mention though that the typical android phone has 3 or 4 different volume sliders for different audio generating processes and the volume rockers usually only control the active sound source, or just ringer volume when no audio is being played. This choosing which slider to control is a bit dodgy sometimes unfortunately.

With my Pandora I can indeed be 100% sure it'll be quiet. But no worries, I'll buy a Pyra anyway

Really I don't understand the problem: I suppose analog wheel in Pyra controls (if not changed for other uses) MASTER volume level, so if you put it low, maximum volume would be low. Even you can add a customization so that when you open Pyra, from off/sleep status, sound be muted or at low level overriding volume wheel.
[doublepost=1460296676][/doublepost]

Everything is controlled by Software to get the maximum flexebility AFAIK

I think so. One example: you want to use Pyra to wake up you or notify some event, and you want it start in low volume, and continue in higher and higher until max volume. If you have master sound in direct analog wheel circuit, you can't up volume above that wheel, but with Pyra analog wheel read in soft, you can do all that without problem.

 

[rygD]

Really I don't understand the problem: I suppose analog wheel in Pyra controls (if not changed for other uses) MASTER volume level, so if you put it low, maximum volume would be low. Even you can add a customization so that when you open Pyra, from off/sleep status, sound be muted or at low level overriding volume wheel.

The stuff Eight Bit was talking about is the same thing I was trying to describe. In Android you only control one of the volumes at a time. It shouldn't be a problem with the Pyra, and if someone dislikes the default we can work on some other options for them.

 

[eric]

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

It's just a form of displacement activity while waiting to be able to order a Pyra...

 

[Klumpen]

It's just a form of displacement activity while waiting to be able to order a Pyra...

 

[Grench]

I've never had issues with any Android phone. If the sound is off, it's off. No crash has ever changed that.

When my Galaxy Note 3 phone crashes it reboots itself. When it powers back on, the power button and the volume button do nothing. Previous volume settings are not loaded yet when it goes FULL brightness and FULL volume to play the Samsung logo followed by the AT&T logo with a Loud BONG BONG BONG! It is enough to be annoying even in a noisy office environment.

If it had an analog volume control I would have a chance in hell to mute it. At worst it would be at my previous volume setting.

In the late 90's there was a joke chain email floating around. If you were dumb enough to click on the link it would max out software volume, unmute if muted, then blast out, "Hey everybody! I'm beating off to porn!" Software based controls mean needing to implicitly trust the software.

1. Analog control as input to software controlled DAC.

2. Analog control directly on the circuitry that feeds the speakers. (Digital mixing pre-control still possible).

I prefer option 2 if it is an option, even if I won't be able to play Arknoid with it. But I'm admittedly a bit of a control freak. I like the idea that I can set the dial and nothing that the device can do programmatically can bypass that. That is true analog control.

 

[Silent-Hunter]

NOO NOO NOO!

 

[EvilDragon]

When my Galaxy Note 3 phone crashes it reboots itself. When it powers back on, the power button and the volume button do nothing. Previous volume settings are not loaded yet when it goes FULL brightness and FULL volume to play the Samsung logo followed by the AT&T logo with a Loud BONG BONG BONG! It is enough to be annoying even in a noisy office environment.

That sounds like an issue with that particular phone, especially as it has a bootlogo sound before it even is powered up.
What does that have to do with the audio control?

Samsung WANTED it to be like this.

 

[Eight Bit]

PD: Offtopic: Where do "?MEMORY OVERFLOW ERROR. / READY" came from? In C64 I know about "OUT OF MEMORY ERROR" and "OVERFLOW ERROR" but no about "MEMORY OVERFLOW ERROR"

Hehe!
You got me