Yay some news!

ClockworkCoder

Chaotic Neutral
Joined
Jan 21, 2016
Messages
1,200
Location
Menzoberranzan
Well not the first, I think the third prototype unit aTc has dealt with. Others devs have recieved prior prototype versions in a less than finished state.
Yes. I'm not sure what the terminology is, but (rightly or wrongly) see this as a first release candidate iteration.
 

levi

Still fresh, damnit!
Joined
Oct 6, 2008
Messages
11,477
Location
Somewhere off the coast of the EU
Yes. I'm not sure what the terminology is, but (rightly or wrongly) see this as a first release candidate iteration.
Yeah, I'm not sure that terminology in that sense has been defined yet. I would discount previous prototypes that aTc has received; in this context we're only really interested in the ones sent out in the past month or two, and to my recollection this is the first one out of the small dozen or so ED was planning to build. Good news in any case though, of course.
 

TrashyMG

Sarcasm Dispenser
Staff member
Joined
Jan 18, 2010
Messages
10,637
Well my point is that people have had prototype units for quite a while and hardware and software development hasn't been totally been hindered with having less that optimal units.

From the comments it sounded like the claim was that nothing has been accomplished until this current version has been sent out.
 

ClockworkCoder

Chaotic Neutral
Joined
Jan 21, 2016
Messages
1,200
Location
Menzoberranzan
From the comments it sounded like the claim was that nothing has been accomplished until this current version has been sent out
Not my intention. Anyone who's spent any length of time on the forums here will understand the roller-coaster it's been so far, and a great deal has been accomplished. We've never been closer to a shippable product before now though (without major issues to resolve first), which is the difference.
 

EvilDragon

Administrator
Staff member
Joined
Mar 4, 2003
Messages
29,265
Age
42
Location
Ingolstadt
Well my point is that people have had prototype units for quite a while and hardware and software development hasn't been totally been hindered with having less that optimal units.

From the comments it sounded like the claim was that nothing has been accomplished until this current version has been sent out.
Well, it's easier if everyone has the same hardware revision which should be final as well :)
 

Letalis Sonus

Advanced Member
Joined
Mar 5, 2009
Messages
1,292
Would save a few % of CPU power (though using ALSA, the mixing seems to have about 1 - 2% CPU usage).
PulseAudio does not support any kind of hardware mixing, though. The daemon only configures a single ALSA instance for all incoming audio data - all the conversion and mixing work is literally forced onto the CPU.
 

levi

Still fresh, damnit!
Joined
Oct 6, 2008
Messages
11,477
Location
Somewhere off the coast of the EU
I just started two instances of mplayer at the same time, and it seemed to play them both mixed simultaneously as far as I can tell. My mplayer is configured to talk pulseaudio natively though, so it doesn't go through the alsa to pulseaudio bridge, so what you say may well be true in that instance. I'd have to deconfigure my mplayer back to use alsa to test that out I guess.
 

Zink

Member
Joined
Mar 8, 2012
Messages
170
PulseAudio does not support any kind of hardware mixing, though. The daemon only configures a single ALSA instance for all incoming audio data - all the conversion and mixing work is literally forced onto the CPU.
Mixing is basically just adding samples together, so not really a hard task for such CPU, even if it needs to do it 48000 times per sedond. Don't know about the conversion though.
 

Letalis Sonus

Advanced Member
Joined
Mar 5, 2009
Messages
1,292
Mixing is basically just adding samples together
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.

Don't know about the conversion though.
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.
 

Grench

Forum Addict!
Joined
Oct 3, 2008
Messages
6,265
So - how do we get the TI DSP driver back into a current kernel?
 

Grench

Forum Addict!
Joined
Oct 3, 2008
Messages
6,265
God knows. It's not something we need to ship units, so I don't think anyone's looking at it at present.
Agreed. But - it would be nice to have a plan?

Prayers, shady money sent to Ti employees, begging and maybe a notaz and a few clones of notaz.
I'm all for cloning of Notaz - but I'd not want to wait 15-20 years for them to become useful. So, we're going to need a time machine first - and you have a sci-fi puppet robot for an Avatar, so you can get to work on that part.

I have this vision of "someone" taking the old/working kernel, building a 2nd version of the same kernel with everything the same but without the TI DSP, then doing an examination of the binary differences... Yeah, not sure where to go with that from there.
 

Pyramancer

Fairly Idle Member
Joined
Feb 4, 2017
Messages
230
Age
119
If you had a time machine you wouldn't go back in time. You'd go forward in time to when the Pyra has been released for a while and all the software goodies are thoroughly polished. You'd get one and bring it back to now so that you'd have your Pyra already.
 
Top