So, what's the current status of everything?

[levi]

English has a regulator; it's called the OED short for the Oxford English Dictionary, all 23 volumes of it. Although as a regulator it's rather descriptive, rather than being prescriptive as an effective regulator would need to try to be, as those last three volumes are additional ones published since the second edition was published (way back in 1989) containing all of the new words they've come across since the original publishing date. Every year they announce a handful of new words they're providing definitions for, and quite often a number of those I've not come across before, let alone am actually using in daily conversation, but presumably someone is.

But at the very least it documents the correct spelling of current and archaic words. I'm not sure whether it now contains the common mispelling of 'definate' (a mispelling of 'definite'), because to my surprise it's not freely available without login yet, so I checked the cambridge dictionary online and chambers in the body, and they don't carry the mispelling, so presumably it takes more than simply the misuse of a spelling for it to be added to these dictionaries at least. Wiktionary carries it as a noted mispelling, which I tend to think it the best way of doing it, although it's kind of academic in the paper edition at least because if you try to look up the mispelling you'll surely come across the right spelling, and the cambridge website does at least suggest the right spelling near the top if you search for the mispelling.

 

[levi]

Since the newly introduced values would be to be expected somewhere inbetween their respective predecessors and successors, but you pull 'em up/down to equal their respective predecessors, I'd say that's introducing more sine waves to the content. I guess, at those samplerates the new content is in too high frequencies to be heard or even to be reproduced in playback. I wonder what became of a sine wave - say at 440Hz - originally sampled at 2kHz, then brought to a rate of 4kHz.

Yes, I think you're right. If you did a fourier transform on it, it'd have to introduce extra sin waves to cope with the fact I'm not even interpolating adjacent samples to smooth out the curves somewhat. But in practice all of those sin waves are supersonic, and physically you're making the sound card act as if it were only capable of reproducing 48kHz samples, and the difference to the diaphrams inside my headphones is probably negligible, if detectable at all.

 

[EvilDragon]

It depends on the OS, firmware, Android ver, music app...

Well, it shouldn't have anything to do with the music app, as it's the Android Soundserver that has ha high CPU load, not the music app.
But yeah, the rest is probably true.

Both are ISA CPU. x86 and ARM CPU are CPU. Why can't you compare them?
It may be difficult to compare because in some cases are in different devices and obviously the run different native code, but we always compared CPUs with different ISAs.

The CPU itself is not the issue.
But if a CPU is 10x faster than an ARM CPU, even if all other parameters are the same, the CPU usage% would be 10x lower as well.

So if we assume has 10x the processing power compared to the OMAP5 in this case, the 30% CPU usage of the OMAP5 would be roughly the same as 3% on your system.

However, the other question is whether it even needed to change the samplerate, as that affects the CPU power more than anything.

 

[oskda]

The CPU itself is not the issue.
But if a CPU is 10x faster than an ARM CPU, even if all other parameters are the same, the CPU usage% would be 10x lower as well.

Of course, there is a problem comparing highly different performance CPUs, but my point is that we can't assume the general rule that x86 is faster or with more performance than ARM, because this is not allays true. For example some Atom x86 CPU can have lower performance than some ARM CPU.

Even ARM originated for DESKTOP computers with more performance than x86 desktop computers form its time. A lot of people doesn't know it, but engineers at Acorn Computers designed ARM for desktop computer because they evaluated lot of CPUs in market, including x86, and they found those CPUs were not good enough, so they designed a CPU themselves from scratch based on RISC principles.

First ARM CPUs, used only in desktop computers, where more advanced and with more performance than x86 CPUs. For example Acorn Achimedes from 1987, was much better and more powerful than most PC from its time. Obviously x86/Microsoft dominated desktop, and ARM wasn't able to penetrate that market successfully so ARM found its place where efficiency and/or cost was fundamental, and so it arrived to mobile devices.

Today we can see ARM in servers, datacenters, and we will see more of them in future.

However, the other question is whether it even needed to change the samplerate, as that affects the CPU power more than anything.

We must wait to do it by hardware. Meanwhile we can convert stored audio to Pyra hard specs, and store it in that format (although that implies more space) so after that we can play it directly without conversion. Of course this apply to stored audio, not to audio generated on the fly for immediate use or transmitted on demand.

PD: I remember lot of years ago I owned a Sony Hi-Fi CD player with a very high bit-count filter (I remember 45 bits, but I am not sure). So CD audio, having only 16-bits resolution, was converted to 45-bits with interpolation. Its sound was incredible (I have never listened audio-CD so good, but it may be I was younger). In this way, while we encode sound for faster frequency and/or higher bit-rate, software can do a good interpolation and it could sound even better than before (Sony did that, or at least that said its advertising, and I felt that way).

 

[matzesu]

I just made a new Place for my Pandora and upcoming Pyra: from the Pocket under the EBook Reader Pocket to the EBook Reader Pocket (Above) so it’s should be much faster to traw the Pyra as I want it to be using much more then my Pandora..

At least Audio works, even if it needs some tweaks, but it’s (just) software and not hardware

 

[sebt3]

pretty stupid by the PulseAudio team.

"Lennart Poettering" is all I had to add here

 

[EvilDragon]

Did you notice ABE requires proper set up in the u-boot and dtb to work? (afaik AESS is the ABE fw and it's configuration sits on the dtb but dont quote me on that I might be wrong)

I've mentioned that on the mailing list and have no idea whether that's done or not (I'm not a coder, myself ), but so far, at least on the mailing list no one has shown any interest.

Ah, sorry, that was my bad. I thought I'd sent a mail out about this, but it seems I only WANTED to do that but didn't do it (I fell asleep a few times between these mails... so that was probably the reason).
So I just found the information on the net but didn't ask that at the mailing list yet.

 

[Confuzzled]

For anyone wishing to understand more about digital media, and audio processing, and why 44.1kHz 16-bit is almost certainly good enough for audio reproduction (but possibly not editing), I strongly recommend watching both the videos on this Xiph.org page:

Xiph.org: Video

xiph.org

Video 1:
"This first video from Xiph.Org presents the technical foundations of modern digital media via a half-hour firehose of information. One community member called it "a Uni lecture I never got but really wanted.""
Video 2:
"The second video from Xiph.Org explores multiple facets of digital audio signals and how they really behave in the real world. Sampling, quantization, dither, band-limiting, and vintage bench equipment all in one video!"

I very, very rarely recommend videos to people. I far prefer to read articles so I can easily skim through, re-read bits I didn't understand, and generally dip into and out of the text easily. These two videos are exceptions, and I can only say I found them well worth watching. More than once.

 

[trix]

It's quite telling that in the two decades I've been using Linux as my primary OS, the biggest, most headache-inducing problems I've encountered have almost always been caused by software written or maintained by Poettering. I've never met the guy, but I seriously despise his software design principles.

While I've generally avoided PulseAudio on my PCs, my wish to be able to switch from bluetooth headset (for calls, headphone usage, etc) to built-in speakers, on the fly, on the Pyra, unfortunately makes PulseAudio too convenient to avoid.

I really wish I had taken deeper, higher-level programming classes when I attended university. I would very much enjoy making it my daily hobby to remake everything Poettering has done, but done better. And by "better" I mean, without his tendency to force his assumptions on use-cases into the software.

Don't get me wrong, the guy is a seriously skilled programmer. I have respect for what he has done. I simply disagree with his design principles (and what I've seen of his attitude) very strongly.

Post automatically merged: Dec 15, 2019

Back on topic - nice to see things are progressing well. I also like that the audio chip in the Pyra seems like it could be quite good. The audio quality in the Pandora was my favorite part of it, and while I'm not sure if the Pyra will reach quite that level, it's good to know it wont be far behind. @MWeston has his name forever recognized in my mind as the genius behind the Pandora's incredible audio capability.

 

[elw3]

Back when kde 3 was fresh and modern, output switching on the fly worked like a charm with kdes inbuild sound settings.
It is a lie that there are no alterantives, but apparently they have been forgotten, lost in data nirvana.
When programming a playback tool it is very easy to switch a soundcard while playing, heck you even have to restart the card whenever the buffer runs empty anyway.
The other part that is needed comes from alsa, dmix, a virtual mixing card that acts as target for all audio programs so that none of them blocks the real hardware.
So why is it so hard to combine booth? This sounds like you only need to set a new output target and have the dmix code restarting without sending an error to the music playing program.

 

[EvilDragon]

I just did a quick test run with my own unit and the current Debian buster we're using.

I booted up and played some videos with FireFox. The speakers really sound beautiful - until they start to overdrive when you turn up the volume too much, but we're working on that.
Not all videos had sound (probably because we don't have non-free codecs installed), but with the ones that played, PulseAudio had around 7 - 11% CPU power while FireFox / Webcontent was using 57% most of the time.

It plays nicely in Windows and fullscreen as well.

Touchscreen is a bit non-responsive directly at the edges, but that's something that's normal for a resistive touchscreen if you don't have lot of space. I worked without any issues and very responsive in the main areas.
Sometimes it registered a wrong value, but these are things the driver can fix.

So yeah, we're getting there.

 

[docbroke]

I love to read this tiny news tidbits first thing in the morning ...

Note: one extra smiley because ED forgot to put one.

 

[EvilDragon]

Played some Stella. Very good test for the screen and the sound. Those Atari sounds sound great

 

[bzar]

Since the newly introduced values would be to be expected somewhere inbetween their respective predecessors and successors, but you pull 'em up/down to equal their respective predecessors, I'd say that's introducing more sine waves to the content. I guess, at those samplerates the new content is in too high frequencies to be heard or even to be reproduced in playback. I wonder what became of a sine wave - say at 440Hz - originally sampled at 2kHz, then brought to a rate of 4kHz.

Nearest neighbor interpolation like that is actually quite common in signal processing. You may get a clearer picture of the process by thinking about images. If you double every pixel the result is a bit pixelated but still recognizable image. Linear interpolation would average the subsamples and produce a bit blurry image (bilinear interpolation in images). Back to sounds, a 48->96 kHZ NN-interpolated signal in *principle* causes exactly* the same physical movement in the speaker as the 48 kHZ one would. If you plot out the resulting analog signal you'll see why.

* not exactly exactly, but close enough for this comparison.

 

[matzesu]

One Moment please: You allready play some Emulators?? Dos this means our MP Pyra want be just Doorstoppers in Two Months ?? , Or are they only Emus from the Debian Repo who needs to Optimice ??

 

[Swordfish II]

It's quite telling that in the two decades I've been using Linux as my primary OS, the biggest, most headache-inducing problems I've encountered have almost always been caused by software written or maintained by Poettering. I've never met the guy, but I seriously despise his software design principles.

While I've generally avoided PulseAudio on my PCs, my wish to be able to switch from bluetooth headset (for calls, headphone usage, etc) to built-in speakers, on the fly, on the Pyra, unfortunately makes PulseAudio too convenient to avoid.

Yep. I have never gotten audio to work on my raspberry pi with pulse. With alsa and alsamixer it works great and outputs can be changed.

 

[Binky]

Nearest neighbor interpolation like that is actually quite common in signal processing. You may get a clearer picture of the process by thinking about images. If you double every pixel the result is a bit pixelated but still recognizable image. Linear interpolation would average the subsamples and produce a bit blurry image (bilinear interpolation in images). Back to sounds, a 48->96 kHZ NN-interpolated signal in *principle* causes exactly* the same physical movement in the speaker as the 48 kHZ one would. If you plot out the resulting analog signal you'll see why.

* not exactly exactly, but close enough for this comparison.

I'm hardly an expert, but I always imagined that modern audio processors do some sort of interpolation to bring the digital signal up to the DACs native sample-rate, and then filtered the signal in analogue-land to eliminate any interesting artefacts left over from the time quantisation.

Trying to interpret a sample-stream as a stepped wave seems clearly the worst option for audio. Real sounds don't have sharp edges in them like that! (Except, perhaps, for detonations and extremely violent impacts?). Other things aside, you'll have trouble finding a loudspeaker that can accurately reproduce step functions...

 

[Eight Bit]

Guys... at 48 and 96kHz... It's not like your eardrums can move that fast....

Also what binky said, analog filter

nerds...

 

[Silent-Hunter]

What's the one in the middle?

 

[levi]

I wonder what became of a sine wave - say at 440Hz - originally sampled at 2kHz, then brought to a rate of 4kHz.

I did that, for the record. The interference on the 4k version seemed to support the tone, and make it louder and sound brighter; in 2k it sounds like it's going through a low pass filter. My code doesn't generate a pure stable sin wave though; it adds odd harmonics to fill out the tone.