As long as that universe has good personal time breaks and isn't too uphill.

> Formula 1 jumped the shark when they disallowed ground effects.

Ground effects whilst technologically interesting suffer from safety problems.

As soon as a car deviates from the optimum ride height for the undertray effects to work the downforce varies significantly. This is a problem when apex speeds are significantly higher due to the extra downforce created by ground effects.

Hit a bump the wrong way and lose downforce == shoot off the corner at much higher speeds into the barrier.

if you've done nothing wrong you've got nothing to fear
if you've something to hide, you shouldn't even be here

(techo beat)

=)

https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3F...

Ten years ago

When we inevitable lose the battle (the government does have a tendency to get their way in these things), do we get to reap the benefits of a total information society? I mean, will there be a searchable database where I can find out where I left my keys? That link to that awesome video i saw on sometube.com that i can't remember? If i remembered to feed the cat?

> Which is what my OP is about, what you suggest we've been there, done that and failed. This is simple functionality that should be handled in kernel with a simple API presented to userspace.

I'd argue that in fact with OSS, we've been there and tried it and it (the Unix write() and ioctl way) fails. (Not to mention you have no idea what I'd advocate, I've just been trying to work out how you'd tackle some of the hard problems with realtime DSP, which you've avoiding answering).

I'll ask again - are you saying to put floating point mixing in the kernel, or fixed point mixing? There are performance and other reasons why floating point register store/restore is avoided in the kernel (in fact some drivers uses these registers as working space IIRC). If you're saying put fixed point mixing in the kernel - this either incurs a penalty in converting everything to that fixed point for mixing _within the realtime processing thread_ or you force every userspace application to output fixed point to the kernel sound API.

Low latency timing information and scheduling is a crap shoot with OSS. How do you know when the sound you are queueing with write() will actually get output? How do you schedule your user-space applications with enough priority that they aren't parked before they get to that critical write() call?

All modern audio APIs have moved away from ioctl and write() to a callback down stack from the interrupt for a reason.

Ignoring this is going _backwards_ from what Jack gives us today.

> you can resample your lower-priority audio outside and feed it through a lock-free ringbuffer. This way the deadline constrained realtime audio has no penalty in practice.

So it seems we agree that running non audio graph canonical formats and rates within the real time processing callback is a silly idea, right?

Now - would you agree that nearly all pro-audio applications and plugins internally work in floating point?

If you are advocating for an in-kernel fixed point mixer for the hardware you will need to perform conversions to fixed point for any output. This seems an unnecessary burn of RT time given we can pass floating point to hardware and do any mixing of it in software with it all in floating point.

Also, I'll point it out again:

"if you're not using floating point you're ignoring the possibility for optimisations using SIMD/FMA instructions"

I'm having trouble understanding what it is you are proposing as a solution.

Are you asking for in kernel fixed point mixing? Out of kernel? Please let me know.

I've done a fair of audio programming too, and the positions of the Jack guys and Poettering are (mostly) understandable.

The bit I don't understand is why Pulseaudio wasn't a "relaxed" mode of Jack with the necessary hardware bits bolted on. Then again the Jack project can't agree to work on one codebase or list of functionality and Pulseaudio can't agree to actually do any low latency work (except they do low latency enough for gaming, sure).

> Despite that most commercial hardware has for ages used fixed point math for this, and that even a simple spline interpolation would do fine for all cases since you are upsampling, most of the "audio gurus" of the linux audio development comunity of the time (like Paul Davis, Steve Harris, etc) convinced the kernel people that there would be a terrible quality loss and it was a bad idea to do this.

One of the problems of using varying sample formats and rates when producing low latency audio is you have now introduced format conversions and resampling inside the deadline constrained realtime audio producing routines.

In addition, if you're not using floating point you're ignoring the possibility for optimisations using SIMD/FMA instructions.

Spouting some bullshit during my lunchtime - would it be possible to make the core molten and thus spin up a magnetosphere by creating an artificial moon?

I'm thinking keep firing asteroids into the necessary orbit until you've accrued enough mass.

Obviously not a "done this week" project just a curious thought experiment.

FYI - Since everyone started twatting and facebooking the newsgroups have come back to life.

The Eternal September has more or less ended - the newbies that can work out how to install a newsreader can't deal with the patience needed waiting for a reply.

I've moved my technical discussions over there and use reddit and other sites as news feeds.

I mean, why didn't slashdot have any news items on the Mill CPU architecture?

If you want to look into revolutionary design changes look into the Mill CPU architecture.

They've put their lecture series available on the web about their intended architecture - it's kinda a hybrid DSP / general purpose with some neat side steps of contemporary CPU architectures.

"Phoronix Forums. You will never find a more wretched hive of scum and villainy. We must be cautious."
- Obi-Wan Kenobi

You're welcome - I hope you get it sorted out.

The only other thing I'd mention - you perhaps noticed I kept saying "threads like.." and "with regular threads" because it's basically introduced a number of single points of failure. Due to the lack of back channel or retransmission, things can go silently wrong without notice (network cable failure etc). In an ideal world you'd double up on some of that infrastructure and networking.

I know you need to get something up and running, but it's perhaps something to bear in mind for a later iteration.

FWIW I agree vis-a-vis using UDP for a business critical thing. I'd want exemption from responsiblity for any missed packets purely due to the infrastructure in between.