So, what's the current status of everything?


..some of this may be a bit over my head, or perhaps I'm miss-interpreting something, but does this mean the audio chip can currently only support nothing but 96kHz 24 bit audio because certain parts of the api aren't quite up-to-date or because the audio chip can't handle anything more/greater than 96kHz 24 bit audio without down-converting it? this sounds troubling...
An audio DAC can always only do one frequency and nothing else. Everything needs to be converted to it.
For the conversion, the chip we use can use an internal hardware. This setup is called the ABE / AESS (ABE is Audio Backend).

So basically, for the current kernel, only the driver for the DAC exists, not for the ABE. So any conversion needs to be done by the software stack, which needs processing power.

That's actual quite common. Most cheap onboard PC Soundcards don't have a hardware conversion, so the CPU needs to do that. But they usually run at 44,1 or 48kHz with 16bit, which means that not a lot of conversion needs to happen.

Good soundcards have a hardware conversion included.

So yes, putting a soundcard in your PC can save CPU power compared to using the internal one. :)
Though with modern CPUs, this is probably not noticeable.

The Pyra has a high quality 96kHz chip in there, which means the conversion is more complex.
That's why it has the hardware conversion included - but we can't use it right now because the driver for it needs to be updated.
 
An audio DAC can always only do one frequency and nothing else. Everything needs to be converted to it.
For the conversion, the chip we use can use an internal hardware. This setup is called the ABE / AESS (ABE is Audio Backend).

So basically, for the current kernel, only the driver for the DAC exists, not for the ABE. So any conversion needs to be done by the software stack, which needs processing power.

That's actual quite common. Most cheap onboard PC Soundcards don't have a hardware conversion, so the CPU needs to do that. But they usually run at 44,1 or 48kHz with 16bit, which means that not a lot of conversion needs to happen.

Good soundcards have a hardware conversion included.

So yes, putting a soundcard in your PC can save CPU power compared to using the internal one. :)
Though with modern CPUs, this is probably not noticeable.

The Pyra has a high quality 96kHz chip in there, which means the conversion is more complex.
That's why it has the hardware conversion included - but we can't use it right now because the driver for it needs to be updated.

16 bit 44.1 kHz is CD quality audio ( I believe ), so 96 kHz 24 bit should be good enough for most music ( which is the best DVD-Video can handle I think ).


thanks for the info! :) I'm not as knowledgeable about all this stuff as I wish I was.

p.s. ED, you don't need to reply to my stupidity any more, just get yourself some sleep! :)
 
Yes



Once again: Money. If I start the production, I have to pay the boards shortly afterwards. But to do that, I need to ship the Pyras so I get the remaining payment from the customers :)
As often said: If you have millions of USD lying around, things are a lot easier as you can simply do stuff when you want, without planning more careful.



Oh, we had sample boxes already years ago and I'll stick with them.
About the Box design... it's already being worked by someone for a few months (the one who made the Japanese boxart of the Pandora).
We won't reveal it though - you'll see it when you receive the unit :)



Yeah, there is a way to donate, but I'm not doing a huge fuzz about. You are all already supporting the Pyra with so much money, I'm really thankful and don't want to be greedy :D

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)
 
For the conversion, the chip we use can use an internal hardware. This setup is called the ABE / AESS (ABE is Audio Backend).
The conversion still has to be done by PulseAudio, though, as it requires a single common sample rate for mixing multiple audio streams into one output stream, implementing ABE/AESS support in the kernel driver will only allow to choose a different target sample rate for PulseAudio without adding yet another level of software resampling (which would still save a lot of CPU power if you choose a more common target sample rate). Is PulseAudio configured to use 96kHz right now? That might reduce CPU load by avoiding doing sample rate conversion twice.

PulseAudio explicitly decided not to support hardware mixing and will always do the mixing and therefore the necessary sample rate conversion in software. I guess you might be able to hack around this by creating a custom resampling algorithm plugin or something like that, though.

PipeWire might be a more sensible choice as it is kind of PulseAudio's official successor that does offer using hardware mixing and things like that, but I have no idea how far its development has advanced by now.
 
Last edited:
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
Comparing x86 with ARM. Nice.

Edit: Wrong FORUM, lol.
 
Last edited:
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.
 
Back
Top