ible
professional vim user
it would be best to assume nothing is getting done while the holidays are in full buy-everything mode (ED is very busy with the shop). if something does get done, it can be a pleasant surprise.
Why the pessimistic view? Is there any reason to think that nothing is being done on the Pyra?it would be best to assume nothing is getting done while the holidays are in full buy-everything mode (ED is very busy with the shop). if something does get done, it can be a pleasant surprise.
Sounds good. *badumtss*Just a quick info about the driver:
The driver is working and we have audio both on the headset and speakers.
We need to fix some parameters in the driver (dc offset and audio gain) so that it doesn't overdrive.
The only real problem with the driver is, that it doesn't support the hardware acceleration right now.
The last known kernel where this still worked is v3.14. Since then, a lot of api changes have been done to the kernel but the ABE / AESS part (this is the hardware acceleration support) has not been updated.
This needs to be done.
The audio chip only supports 96kHz 24 bit audio. So anything that has a different frequency (which is basically everything) needs to be samplerate converted.
With the current driver, this is happening in software (and thus pulseaudio used 30% CPU when playing with Drastic).
The ABE / AESS support would do this in hardware, so no CPU power used.
That's all Sound is working, just needs some CPU power.
The only real problem with the driver is, that it doesn't support the hardware acceleration right now.
The last known kernel where this still worked is v3.14. Since then, a lot of api changes have been done to the kernel but the ABE / AESS part (this is the hardware acceleration support) has not been updated.
This needs to be done.
The audio chip only supports 96kHz 24 bit audio. So anything that has a different frequency (which is basically everything) needs to be samplerate converted.
With the current driver, this is happening in software (and thus pulseaudio used 30% CPU when playing with Drastic).
The ABE / AESS support would do this in hardware, so no CPU power used.
An audio DAC can always only do one frequency and nothing else. Everything needs to be converted to it...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...
Is it this chip ?
You should try that one day, but I wouldn't be surprised, if you report bleeding ears.48 goes into 96kHz a lot easier (just repeat each sample twice)
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
I just did, albeit with a pretty short sample. It sounded fine to me; what did you expect?You should try that one day, but I wouldn't be surprised, if you report bleeding ears.
Can someone update this page https://pyra-handheld.com/wiki/index.php?title=Audio with information about audio chip.No, we're using the TWL6040.
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
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.For the conversion, the chip we use can use an internal hardware. This setup is called the ABE / AESS (ABE is Audio Backend).