So, what's the current status of everything?

[EvilDragon]

I don't think that is normal. My current laptop with AMD A10 is consuming 1-2% CPU power only, when playing audio using mpv/pulseaudio. I tried with different audio files ranging from mp3 to flac.

Ah well, there are a lot of different factors to take into account.
First, what rates does your soundcard support and what rate is Pulseaudio set to?

If you play a 44,1kHz audio via PulseAudio with a target rate set to 44,1kHz and the soundcard also supports that natively, no samplerate conversion happen.

We can play a 96kHz / 24bit audio on the Pyra as well and the CPU usage is very low.

And, of course, your CPU... depending on which one you have, it's more powerful than even the GPD Win 2 - and that's a lot more powerful than the Pyra or most smartphones.
So yeah, of course it uses a lot less CPU

It's all a matter of configuration. By default it should use 48kHz AFAIK, but if you configure it e.g. for 44.1kHz it will happily convert an incoming 48kHz to 44.1kHz for mixing, which then will be resampled back to 48kHz if the device does not support 44.1kHz.

aTc did the PulseAudio setup, but I'm not sure if he changed anything from the default config.
I guess as default config, PulseAudio will use whatever rates the audio chip supports - and as our only reports 96kHz as supported audio, it should hopefully switch to that.
But it's something we should check, a double conversion would be bad.

There's still a lot of 44.1kHz out there, especially music tracks still use it a lot. A lot of notification sounds and retro games even like to use 22050Hz. 44.1kHz vs 48kHz is a tricky question, I'd still prefer the former.

I think 48kHz is mostly used in video (as it was the standard for MiniDV and DV tapes). Apart from that, most games and music tracks still default to 44.1kHz. Well, or stuff like emulators as well (or 22050Hz, as you mentioned).

Some OMAP4 documents provide some hints that the TWL downstream port can also be configured for 88.2kHz, which would be useful for 44.1kHz audio - someone got more info about that?

Yes, that's the low-power mode. The rate is also in the driver sourcecode, but I don't know yet how to enable low-power mode.
The driver is this one:

Golden Delicious Computers - letux-kernel.git/blob - sound/soc/codecs/twl6040.c

Post automatically merged: Dec 14, 2019

And on an update: While the DigiKey package arrived, the part I needed to modify the Display board to change the prototypes to basically the final version wasn't in the package. Meeeh,
So I can't update the display boards.

But I still can check and work on the mainboards, as I have everything for that here

 

[Djoga'Ro]

I just did, albeit with a pretty short sample. It sounded fine to me; what did you expect?

I'd expect, that the result of the process you described, describes a very different ausio signal. How/with what tools did you produce your test sample?

 

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

 

[levi]

I'd expect, that the result of the process you described, describes a very different ausio signal. How/with what tools did you produce your test sample?

A simple python script I entered interactively. I have a short sample called beep for one of my projects that's not very representative as music, but should be enough to check the basics. It's actually raw sample data at 44.1kHz, so I pretended it was 48k source for simplicity and converted that to ogg for playback, and then wrote my python script. It's basically:

with open('beep.raw','rb') as f:
  with open('beep96k.raw','wb') as o:
    s=f.read(2)
    o.write(s)
    o.write(s)

Then I passed that through ffmpeg telling it that the -ar (audio rate) was 96k to get an ogg file I could playback, and it's indistinguishable for my ears from the 48k version.

 

[oskda]

A language which only governmental or similar organizations can regulate? Clearly a red flag from an adoption perspective. It is a too tempting way into really ugly totalitarian regime.

Unless there is a brutal totalitarian force behind enforcing the regulations and controlled development of the language, the natural evolution can still happen, regardless of the regulation.

Enforcing a regulations on people's native language is annoyance. An attempt to enforce a construed language foreign to the native language might be viewed by many as a reason to active (eventually even military) resistance.

I think you are totally confused. Only you think in totalitarian, brutal totalitarian, red flag, regime, enforcing, military

Even I don't know what part in my text makes you think that horrific way. Really strange.

1/ It would be a 2nd language, a constructed international auxiliary language. It won't be your only language nor your natural/born/1st language. It doesn't pretend to replace natural languages, only facilitate communication, equality and over all ACCURACY

It us not "use this, and only, this or I'll xxxx you". In fact the natural languages were imposed that bad way you think: a dominant nation arrives to other place and imposes its language (by force, by cultural invasion, by persuasion "it's better for your business/education/etc", or by a mix of all them). Roman empire, Spanish empire, British empire and even much other smaller powers, DID THAT.

2/ To use a standard is not totalitarianism. We use standards all time, and we have no problem. For example most world use metric system (and others use old imperial system, other older STANDARD), lots of standards for all. Even in computing we use all type of standards. Are we totalitarian for that? I don't think we are.

3/ The standard can be made by international organizations (imagine for example ONU).

4/ A constructed international auxiliary language makes all people have the same optional language for communication, where all them have the same possibilities: because it is not natural/born for some, and it is a standard defined language, so you can know exactly how to use it by that standard, as you do with standard versions of computer languages.

In natural languages you see the opposite: the "same" language is differently spoken by different people (even in same country) and they all are full of illogical forms, irregularities, inconsistencies, etc. Natural language evolution is so ugly and imperfect

Now we are using an imposed language (I haven't choose it freely; when I studied I had to study it as 2nd language). Are we, or our teachers/education, totalitarian for that? No, but we end with an imperfect language and the problems derived from it.

My native language is supposed to be governed by some kind of "scientific" institute, yet the institute basically codifies what the people do with the language (or, more precisely, how speak the people in the country's capital).

Your language (if it isn't English), and mine, are governed by official institutions usually only afterwards. Language evolves, more times in bad way, and that institution over time accepts that changes. I don't know what your natural language is, but I can say mine is being mutilated by natural speakers (they do awful errors) and by institution (finally accept that errors downgrading language).

But the more funny stupidity is precisely that English language is one of the languages NOT having a formal regulator anywhere (it isn't English regulator is weak/soft, simply there is no regulator ). And we must use that language.

You can see in this link a list of natural languages REGULATORS (most of them official/government institutions)

For example Italian, French, Spanish have official language regulators. The same for German, I think, at least for grammar.

PD: I try to left this language discussion, as it is too much off-topic

 

[ClockworkCoder]

PD: I try to left this language discussion, as it is too much off-topic

I'd really appreciate it if you did take this conversation elsewhere, especially as we have been getting new tidbits of news.

 

[pmprog]

Animations can be turned off in other ways, but that ends up hacking around in developer options. It's certainly something Google do not want us to do.

Just go in accessibility options, you can do it from there without developer options

 

[Djoga'Ro]

A simple python script I entered interactively. I have a short sample called beep for one of my projects that's not very representative as music, but should be enough to check the basics. It's actually raw sample data at 44.1kHz, so I pretended it was 48k source for simplicity and converted that to ogg for playback, and then wrote my python script. It's basically:

with open('beep.raw','rb') as f:
  with open('beep96k.raw','wb') as o:
    s=f.read(2)
    o.write(s)
    o.write(s)

Then I passed that through ffmpeg telling it that the -ar (audio rate) was 96k to get an ogg file I could playback, and it's indistinguishable for my ears from the 48k version.

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.

 

[Xcl4m4t10n]

Oh, wow. Just played audio on my Android smartphone and noticed it uses over 20% CPU power as well :O
Is that normal?

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

 

[oskda]

Comparing x86 with ARM. Nice.

Edit: Wrong FORUM, lol.

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.

 

[ClockworkCoder]

Just go in accessibility options, you can do it from there without developer options

Thanks for the suggestion, but I don't have any options to disable animations there on my phone. Just high contrast, large fonts, google assistant, etc.

The point is, commercial devices will always cater to the masses. Small, independent devices (i.e. the Pyra) cater to a small, quite technical audience. I'm so ready to leave Google et al. behind...

 

[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

 

[Xcl4m4t10n]

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.

Did you read the whole message or did you just stop to read when you want?

 

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