So, what's the current status of everything?


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.
 
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?
 
Indeed, a view of the kernel mailing list at least shows there's more than ED working on it. Although last I heard, hns was trying to read up on the audio subsystem to start to debug it, although he'd coming from basically a very low start, so I'm not expecting any news from that front just yet.
 
Well, it's not strictly not working, it does create devices for the speakers and the headphone port and they work (as long as you don't overdrive them), but it also creates some extra fake devices that crash the kernel if you try to access them, which I'd imagine breaks pretty essential things like alsamixer and pulseaudio configuration screens.

Edit: And thus I can imagine benefits from sending out prototypes to testers and devlopers. At least it'll get more people noticing what's broken and making noise about it, even if none of them can help explicitly in fixing it.
 
Thos extra audio devices are not a problem though, as these exist as a result to try to load the firmware. If we use the mainline driver, these won't be there.

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.

Oh, and BTW: Yep, I didn't post because I was horribly busy with work. Basically, I didn't even find the time to play some games within the last week.
Preparing and shipping for christmas, organizing some Pyra stuff, finishing taxes, producing 2100 UltraCore MegaDrive carts, etc.

The parts I need to work on the prototypes have arrived just today. I've reserved the full weekend to test and fix any issues with the boards so I'll hopefully have these ready end of the weekend to prepare the prototype shipment.
Yep, we're close to christmas, but I try to finish them.

As long as I don't overdo it and fall asleep during work (happened 2 or 3 times within the last weeks), I should be good.

The good news is: I'm not dead yet :D
 
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.
Sounds good. *badumtss*
 
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.

..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 ?
image.jpg


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 ).
 
Last edited:
Yes, it should be 'enough' but it still takes significant CPU time to interpolate between 44.1 and 96kHz. 48 goes into 96kHz a lot easier (just repeat each sample twice), which I guess is why most audio these days is 48kHz while the 44.1kHz that was designed to adapt well to the human ear is less common. It may be good enough to repeat the sample twice most times but repeat each 10th sample three times, but that'd be out by just over 1/100, such that a 3 minute pop song would end up being 1.8 second too long, which might cause awkwardness in games that play their samples sequentially (and it would also alter the pitch of the samples, but I'm not sure what 1/100 sounds like as a pitch delta off the top of my head)
 
..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:
Back
Top