ible
professional vim user
you'd drive the perfect pitch people nuts. everything would sound a bit flat.
So, what's the current status of everything?
- Thread starter EvilDragon
- Start date
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.
No, we're using the TWL6040.
Djoga'Ro
moonstruck
- Joined
- Apr 3, 2016
- Messages
- 2,499
You should try that one day, but I wouldn't be surprised, if you report bleeding ears.
ImmaculateChimp
Member
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 ).
eClassical.com 24-bit FLAC lossless Classical Music Download Store
About audio formats FLAC and MP3 At eClassical, we now offer much of our music in three file types: MP3 320 kbit/s (near CD quality) 16-bit FLAC (CD quality) 24-bit FLAC (studiowww.eclassical.com
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!
levi
Still fresh, damnit!
I just did, albeit with a pretty short sample. It sounded fine to me; what did you expect?
Can someone update this page https://pyra-handheld.com/wiki/index.php?title=Audio with information about audio chip.
Chaosruler972
Still Fresh
- Joined
- Apr 3, 2018
- Messages
- 9
- Age
- 32
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
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)
Letalis Sonus
Advanced Member
- Joined
- Mar 5, 2009
- Messages
- 1,530
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)
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)
Letalis Sonus
Advanced Member
- Joined
- Mar 5, 2009
- Messages
- 1,530
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.
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.
Oh, wow. Just played audio on my Android smartphone and noticed it uses over 20% CPU power as well :O
Is that normal?
Is that normal?
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
The Pyra is a bit less power so it’s good to get the CPU Usage Optimized
Xcl4m4t10n
Advanced Member
- Joined
- Dec 18, 2009
- Messages
- 1,209
Comparing x86 with ARM. Nice.
Edit: Wrong FORUM, lol.
Edit: Wrong FORUM, lol.
Last edited:
ClockworkCoder
Chaotic Neutral
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..
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..
Letalis Sonus
Advanced Member
- Joined
- Mar 5, 2009
- Messages
- 1,530
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?
ClockworkCoder
Chaotic Neutral
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.
