... we're still alive!


Is the final volume control (in the DAC?) digital or analogue?

I know some poor-quality devices are arranged so that if you reduce the volume to a quarter, you lose 2 bits of playback quality.
If the samples being operated on are low precision to start with, that could be a problem. i.e

12bits of precision / 4 = 10 bits of precision ==> bad
32bits of precision / 4 = 30 bits of precision ==> fine
 
Is the final volume control (in the DAC?) digital or analogue?

I know some poor-quality devices are arranged so that if you reduce the volume to a quarter, you lose 2 bits of playback quality.
If the samples being operated on are low precision to start with, that could be a problem. i.e

12bits of precision / 4 = 10 bits of precision ==> bad
32bits of precision / 4 = 30 bits of precision ==> fine
Why the hell? How does that even work?
 
Well, it's pretty basic maths. 16-bit (signed) numbers go from -32767 to +36768. If you play back a 16-bit sound file where all the samples are in that range on a system that can only reproduce those it'll work fine at full blast. But if you reduce the volume in software by half it maps that 16-bit range onto numbers that go from -16383 to +16384 - you've lost a bit of information to make a 15-bit number. And 14-bit if you go to quarter volume.

But if you play that same 16-bit audio file on a system that support 24-bit numbers, at 100% volume it will put those 16-bits of information in the top 16-bits of the 24-bit number - i.e. stick 8 zeroes in the bottom bits. At 50% volume it will put them one bit lower, with a zero in the top bit, then the 16-bits of numbers, and 7 zeroes at the end. And 25% volume one step further. Only when you get down to 1/256th of maximum volume does it reduce the resolution of the signal.

In practice there are ways to reduce the apparent data loss, by adding up to a bit of random noise depending on the bits lost - but that's the same as anti-alising in computer graphics, where you add grey pixels to disguise the jagged edges - a bit of a hack.
 
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.
From one of your earlier posts (months ago) it sounded like the audio type decision was pending some testing on the prototypes. Both methods were traced on the boards. Were the tests still pending or is it done and moving forward? I will defer to your judgment.
 
Well, it's pretty basic maths. 16-bit (signed) numbers go from -32767 to +36768. If you play back a 16-bit sound file where all the samples are in that range on a system that can only reproduce those it'll work fine at full blast. But if you reduce the volume in software by half it maps that 16-bit range onto numbers that go from -16383 to +16384 - you've lost a bit of information to make a 15-bit number. And 14-bit if you go to quarter volume.

But if you play that same 16-bit audio file on a system that support 24-bit numbers, at 100% volume it will put those 16-bits of information in the top 16-bits of the 24-bit number - i.e. stick 8 zeroes in the bottom bits. At 50% volume it will put them one bit lower, with a zero in the top bit, then the 16-bits of numbers, and 7 zeroes at the end. And 25% volume one step further. Only when you get down to 1/256th of maximum volume does it reduce the resolution of the signal.

In practice there are ways to reduce the apparent data loss, by adding up to a bit of random noise depending on the bits lost - but that's the same as anti-alising in computer graphics, where you add grey pixels to disguise the jagged edges - a bit of a hack.
Yes but why does changing the volume entail that type of reduction?
 
To the ppl with dev boards:
From VLC, if you mute, will that mute the volume for all other applications?
(On the Pandora, muting or setting volume in VLC does nothing)
 
Yes but why does changing the volume entail that type of reduction?
Lowering the volume equals lowering the amplitude of the signal and therefore lowering the value of the sample, which always involves loss within the digital realm because the upper bits start to become useless at some point - it can be countered by using a few more bits in hardware, e.g. a sound controller applying the volume digitally in hardware could use an 18bit DAC that it feeds with 18bit samples to get rid of the data loss from reducing the volume of 16bit samples. Increasing the sample size means adding precision, scaling down requires more precision - ideally you don't want to get less than 16bit worth of data anywhere.

When you're changing the volume the analogue way you only need to care about noise distorting your signal (which is not necessarily an easy task).
 
Was thinking, the up-side of having the digital analog volume wheel, is that it can control bluetooth audio too I guess?

Sure, and HDMI audio, speaker audio, headset audio, etc.
A hotkey for switching between all PulseAudio sources could be created, so you could change the volume of any app, any output, etc.
These are all different devices and sources, you can play something else through the speakers than through bluetooth or the headset.

Per default, the volume wheel should be routed to MASTER though, it would only confuse people otherwards.

From one of your earlier posts (months ago) it sounded like the audio type decision was pending some testing on the prototypes. Both methods were traced on the boards. Were the tests still pending or is it done and moving forward? I will defer to your judgment.

They're both on the prototype boards, but that might be a lot of work, so I'll probably only test it, if the other audio has any issues.
At least, I can easily compare it to an original Pandora.
 
When you're changing the volume the analogue way you only need to care about noise distorting your signal (which is not necessarily an easy task).
Please note that similar problems occur in analogue amplification and signal propagation though. The signal/noise ratio could be as high as 0.01%, meaning a ten thousandth of any given signal is noise. Since the quietest sound a 16-bit source can make is a 65000th meaning approximately the bottom three bits are lost to noise. Reduce the amplitude at source by half and you lose four bits to noise. I guess that's why most volume controls work on the amplified signal after the power stage where the signal level is higher, so any noise introduced will have less of an effect.

I've no idea what the s/n ratio of the pandora's sound system is, but I can definitely hear the charging circuit if I'm using my best headphones and plug in my Pandora to the charger, and using my 1/10^10 s/n ratio hi-fi amplifier I can tell the difference in noise between the line out at the back and the attenuated headphone port, though to be fair the way I wired up the headphone port to it probably means there's an impedance mismatch causing reflections along the cable. The Pyra doesn't really have a lot to live up to in terms of s/n I suspect, so the main thing to be tested IMO is whether it reproduces the pitches and harmonics as well as the Pandora's DAC and amp does.
 
The Pyra doesn't really have a lot to live up to in terms of s/n I suspect, so the main thing to be tested IMO is whether it reproduces the pitches and harmonics as well as the Pandora's DAC and amp does.
According to ED's audio test this is exactly what the new audio circuit will not do. The Pandora audio circuit produced a higher level of noise, but it was quite nicely distributed among the harmonics while the new audio circuit just had the 'normal' artifacts associated with a DAC. To an audiophile (which I'm not; only an observer) the two will most probably sound very different (and I wouldn't be surprised if the Pandora is deemed the better of the two, even though the Pyra sound may technically be more exact).
 
In practice there are ways to reduce the apparent data loss, by adding up to a bit of random noise depending on the bits lost - but that's the same as anti-alising in computer graphics, where you add grey pixels to disguise the jagged edges - a bit of a hack.
Usually (maybe it's different in real-time rendering nowadays), AA is just over-sampling (in a dozen different ways) each pixel.
 
One of the reasons I was so excited for the Pandora audio wheel coming from the GP2X was because we had a dedicated audio management control that no one else could repurpose for something other than audio. Sadly, making the audio wheel software controlled on the Pyra removes that advantage. It's not a dealbreaker, of course, but it certainly isn't palatable.

-God Ginrai
 
If that's a major problem, you're meeting with the wrong people. And being near sleeping babies is a problem solved, when the device goes crazy.

My smartphone has no analog means of sound output reduction either, and there are still places, I can go.

i had problems with the GP2x and was very happy that the Pandora had an actual vol
me wheel wher I could turn the volume down to 0 and could then use my it in bed.
So, I would be very happy if the Pyra would be the same, although it is not a dealbreaker for me.
 
One of the reasons I was so excited for the Pandora audio wheel coming from the GP2X was because we had a dedicated audio management control that no one else could repurpose for something other than audio. Sadly, making the audio wheel software controlled on the Pyra removes that advantage. It's not a dealbreaker, of course, but it certainly isn't palatable.
Wait, so the value in your device, is that other people can't do something with their own devices?
 
like using it for games, and not making you miss an alarm because you forgot to spin it to the right).
You should not expect to be able to use it in games.
Recently, I played Kaboom on my Atari 800XL with a paddle. The precision you need is not doable with a volume wheel. From min to max, on the Atari, there are 229 values. You can not get this resolution with such a tiny wheel.
 
... They're both on the prototype boards, but that might be a lot of work, so I'll probably only test it, if the other audio has any issues.
At least, I can easily compare it to an original Pandora.

(thanks grench for asking my earlier question in a much clearer way.)
perfectly understandable to reduce complexity and keep the cost/work todo lower at this stage of development, to get pyra out to us as soon as possible.
so welcome ti palmas-power-audio! at least ti bought burr-brown some time ago, so there might even be their genes in the ti palmas. ;)

update: and thanks levi for those interesting audio tech explanations!
 
Last edited:
You should not expect to be able to use it in games.
Recently, I played Kaboom on my Atari 800XL with a paddle. The precision you need is not doable with a volume wheel. From min to max, on the Atari, there are 229 values. You can not get this resolution with such a tiny wheel.

The Pyra's wheel should have enough resolution - I can't find the source post right now, but I think someone said it was about 10-bit resolution, so 1024 values. But agreed, playing a game where you can slam your wrist round to go from min to max and still get fine grained control if you want it on a wheel where you keep having to take your thumb off it and recompose isn't really going to work - it's just a funny idea IMO.
 
You should not expect to be able to use it in games.
Recently, I played Kaboom on my Atari 800XL with a paddle. The precision you need is not doable with a volume wheel. From min to max, on the Atari, there are 229 values. You can not get this resolution with such a tiny wheel.
Practicality isn't the point (plus I may get better with practice). I play FPSs on my Pandora with the built in gaming controls often enough, and that is a very poor choice, as well.

Like levi said, it is mainly a "because I/we can" thing.
 
Last edited:
Wait, so the value in your device, is that other people can't do something with their own devices?

Spoken like a person who never used a GP2X. When you make the volume control through software, people have to support it for it to work. That's why plenty of games for the GP2X forced you to go into menus to change the volume, or worse: didn't even allow you to change the volume in game. You had to literally exit the game, change the volume, and then start the game again for those. This exact problem can arise on the Pyra if people try to use other images like they did on the Pandora. (Android, Arch, etc.) Because they will have to support the volume wheel rather than it just working.

-God Ginrai
 
Back
Top