So, what's the current status of everything?


Ouch, now that's an interesting information.
Still, setting up the most common sample rate used in games as default sample rate would safe a lot of CPU power, but that sounds pretty stupid by the PulseAudio team.

I also plan to test the differences in CPU usage of Pulse ad Alsa when playing the same song, but Pulse has a lot of nice features ALSA doesn't have (like redirecting audio streams on the fly)
 
but that sounds pretty stupid by the PulseAudio team.
Poettering wanted to create a solution for common desktop users, so he explicitly targeted the average motherboard audio codec - from that perspective hardware mixers are non-existent and you got plenty of CPU for software conversion and mixing. Use PulseAudio for anything too far from that and it will screw you over...

You can select the resampling algorithm used by PulseAudio and therefore choose how much quality you want to sacrifice for less CPU load, though. I guess configuring PusleAudio to actually use 24bit samples for its output might allow for using fairly simple algorithms without manhandling the signal too much.
 
Last edited:
Hm, but afaik, the ABE of the TWL6040 should be transparent.
Right now, all audio devices claim that they only support 96000 Hz. With ABE included, there should be audio devices available that support multiple frequencies and they do the hardware samplerate conversions without the software even knowing it.

Surely Pulseaudio would not convert an 48kHz stream if the device supports that frequency, would it?
Because that would be pretty stupid.

Well, of course... when you're mixing, you always have to convert some of the rates in software because there's only one given target rate. But I don't think that's any different in ALSA.
 
Should be normal: Android is one OS for all Smartphones, and I suppose the Company ditnt care about CPU Use, because they have enough Power..
The Pyra is a bit less power so it’s good to get the CPU Usage Optimized
 
  • Like
Reactions: rSl
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.
 
  • Like
Reactions: rSl
Should be normal: Android is one OS for all Smartphones, and I suppose the Company ditnt care about CPU Use, because they have enough Power..
The Pyra is a bit less power so it’s good to get the CPU Usage Optimized

Ironic as battery life is shocking on most smart phones. I wish I could switch off animations or fancy effects at the very least for slightly better battery life, so it will be fantastic to finally get a power-efficient device :)
 
There is a Battery Save option at least on the Phones I had, so some animations and background things are disabled, ..

So Sound works on Pyra currently but needs to many CPU Power??

It’s cool that whe get that many Background Infos on Pyra Development..
 
Surely Pulseaudio would not convert an 48kHz stream if the device supports that frequency, would it?
Because that would be pretty stupid.
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.

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.

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?
 
There is a Battery Save option at least on the Phones I had, so some animations and background things are disabled

For me too, but it doesn't disable all animations, and is turned off again every time the phone is plugged in. 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.
 
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:
Post automatically merged:

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 :)
 
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?
 
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.
 
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:
Code:
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.
 
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 :D

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 xD). 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 :)
 
Last edited:
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
 
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:
Code:
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.
 
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.
 
Last edited:
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...
 
Back
Top