Yay some news!

[Wally]

Now now, let's not get philosophical here, we all know that'll end up being 20 pages of this topic.

 

[directive0]

Today is 1st of June,
Half of the year is GONE.

Just saying...

Hell, we've all waited this long. What's a few more years?

I think things are looking good! I can't tell you how much I enjoy reading about pyra development even when it's not always good news. It's going to be a surreal experience to actually hold one in my hands.

 

[netlinker]

If you "basically just add samples together", you'll end up with lots of clipping and distortions. It takes a lot more math to mix audio samples together without thrashing them, especially if you need to mix more than just two streams together. Many implementations use dynamic compression, exploiting the ability to look ahead for a few samples. Hardware mixers usually just throw more precision at the problem to keep things relatively simple and lossless.

There's a reason why many audio frameworks switched over to using float samples internally.


PulseAudio has a wide selection of available resampling algorithms - you can throw a LOT of CPU cycles at this task if you want a good audio quality.

As far, as I'm familiar with math, float is only necessary for resampling as you need to calculate the time interpolation of the waveform (did this already several times). For a linear mixing job, one would simply add the channels (most usecases). Also float could be ommitted, as the Neon should be able to do 128bit of Single Cycle hardware multiply in int. This should be more than enough resolution to mix 2^96 Channels of 32bit without overflow. If you want lets say 10 bit resolution for a scaler, you would end up with a calculation that needs be 45 bits wide for 32bit resolution, 8 ch (3bits more) and 10 bit prescaler. So even 64 bits would do.
But If you really like float, almost all cpus can do a single cycle float multiply. I'm not sure though if a matrix operation exists.
The neon core should be able to do a 4x4 single cycle matrix multiply (int) or MAC with saturation for even faster results, so ... is 16 samples per cycle at 1.5GHz enough? (CPU usage of 0.006% for mixing + some % for overhead ... way less than 0.1%)
I'm pretty sure also the m4 coprocessor could handle this for low power operation (also has single cycle multiply, but no matrix operations as far as I know).
The DSP would be overkill for this task, at least, if you don't want to mix 512 Channels at 192 kHz . It would eat through your cpu like a hot knife through butter ... just for some Audio. IMO the DSP is better suited for Video stuff like transcoding, or complex audio calculations, like echo removal (telephony), transcoding etc.
I believe, in the long term, one should be looking into the Ducati Subsystem of the OMAP for good multimedia performance one day.
I'm familiar with Microcontroller programming, but didn't touch anything related to kernel stuff yet .

 

[Djoga'Ro]

I can't tell you how much I enjoy reading about pyra development even when it's not always good news. It's going to be a surreal experience to actually hold one in my hands.

That reminds me of Heath Ledger in heavy make-up.

 

[Letalis Sonus]

For a linear mixing job, one would simply add the channels (most usecases).

You still need to normalize the result, which is the tricky part. Even when you stick to doing it linearly, normalizing integer samples takes a lot more precision to remain lossless.

 

[matzesu]

@Wally :
Thanks for this News, it’s a good idea to take this work from EvilDragon,
According to the meaning: seems like there are some things left to do,
But it’s still better to fix the issues now than 1000 Pyras out in the Wild whit this Issues..

When I’m thinking on the State of the Pandora, when I got my Unit, I think it’s OS should already be more useful than at these old days..

 

[Grench]

4. Installation of the OS and booting from eMMC is now working!

It feels like we haven't made enough of a big deal about this - it is a pretty big deal. This means that the Pyra can now work 'out of the box' without any additional media. If ED & group were not so overloaded already, I'd ask for a 'hello world' video of the Pyra booting from battery off of the internal eMMC with no cards or cables.

 

[ClockworkCoder]

If ED & group were not so overloaded already, I'd ask for a 'hello world' video of the Pyra booting from battery off of the internal eMMC with no cards or cables

And try running Gimp again

You're right though, this _is_ a big deal (re "eMMC now working")

 

[Pyramancer]

It feels like we haven't made enough of a big deal about this - it is a pretty big deal.

I agree. I felt that this was the biggest piece of (positive) news on Wally's list. We've been waiting for word of this working for so long that I've been increasingly worried that some problem would crop up preventing it from being achieved without a major delay. It's a great relief to hear that it's working.

 

[directive0]

It feels like we haven't made enough of a big deal about this - it is a pretty big deal. This means that the Pyra can now work 'out of the box' without any additional media. If ED & group were not so overloaded already, I'd ask for a 'hello world' video of the Pyra booting from battery off of the internal eMMC with no cards or cables.

A "plugs out" test of sorts. Yeah that'd be great!

 

[netlinker]

You still need to normalize the result, which is the tricky part. Even when you stick to doing it linearly, normalizing integer samples takes a lot more precision to remain lossless.

I know, thats what the extra 10 bits were meant for. But with a 64 bit multiply you could actually expand it to a 29 bit at no cost which should usually be enough for normalizing.
One would have to "test hear" the result tough. I agree that with integer you have to be a lot more careful than with float.

 

[Grench]

I know it is very early - but I'm also wondering now about the state of the internal microSDXC slot. Patience though - the eMMC working and booting is a huge step forward.

 

[Xcl4m4t10n]

About PinePhone:

After a chat with developers, we also came up with a way to expose I2C using 6 pogo pins. These pogo pins will be located directly on the PCB. The idea behind this implementation is that entire back-covers with add-on components can be created (even 3D-printed) with additional functionality to enrich the phone’s functionality. The implementation only requires that the custom back-cover with additional hardware has the same dimensions and position of plastic latches as the original – and obviously that the component in question uses I2C (contact pads). I expect that a back-cover with a keyboard – perhaps one similar to that found on the Nokia N900 – will be something a considerable number of people may be interested in creating. To this end, we’ll make sure to have detailed documentation on this feature. I really hope that the hackers and tinkerers among you will embrace and make use of I2C for new cool implementations.

 

[Grench]

About PinePhone:

I am usually on-board with the natural flow of conversations to go off topic in an organic manner. But, what is the relevancy of that to this news thread about Pyra development?

 

[Xcl4m4t10n]

I am usually on-board with the natural flow of conversations to go off topic in an organic manner. But, what is the relevancy of that to this news thread about Pyra development?

If you read, you can catch the conclussion. It's more on-topic than you think, try it again!

 

[levi]

I think you might need to be more explicit about that.

 

[WizardStan]

Are you... trying to make this a keyboard thread?

 

[NutNut]

Are you... trying to make this a keyboard thread?

Plz no. Current keyboard is perfect. Plz2keep keyboredom to yourself

 

[ible]

i feel like all the newbies just have no idea the painstaking detail we argued over discussed to come up with an excellent Pyra keyboard. how will they ever appreciate the hours spent? the dedication? the joy, the tragedy, and the final triumph?

 

[comradekingu]

By hacking away at the physical layout, rearranging buttons, and then adding some language-specific typing paradigm that 10 other people in the world use.