**** BEGIN LOGGING AT Sat Dec 05 02:59:58 2015 Dec 05 03:10:44 note that the L3 interconnect is actually a packet-switched network, so using the term "firewall" isn't that strange (the a8 sram doesn't reside on the L3, but still it's not a big stretch) Dec 05 03:13:24 but why would you worry about security at that level? is this for IP protection or somesuch? Dec 05 03:14:13 i.e., why have a firewall at all? Dec 05 03:14:42 this tech can ultimately be traced back to its OMAP heritage, on cellphones you have untrusted linux running alongside secrety-cellphony-stuff Dec 05 03:16:17 although I would encourage people to start using the firewalls more actively to prevent stray writes from a misbehaving core or DMA engine to fuck things up elsewhere... such bugs would be terrible to debug, and easily prevented with firewalls Dec 05 03:16:34 that will become especially important on a heavily multicore environment like the beagleboard-x15 Dec 05 03:17:53 isn't that part of what the MMU is supposed to handle? Dec 05 03:18:09 MMU keeps processes on the same cpu out of each other's hair Dec 05 03:18:31 but there's no over-arching chip-level MMU Dec 05 03:19:52 if some PRU application messes up its pointer logic and on rare occasion writes to some page of code or data of a linux application or the linux kernel, which later crashes, how on earth are you to debug that? Dec 05 03:21:50 likewise the GPU depends on the driver to pass it correct pointers to framebuffers and such; a mistake in the driver (or in the microkernel running on the gpu) can yield the same problem Dec 05 03:21:56 i don't know how such things work. how does the x86 keep things from hosing up? Dec 05 03:22:12 the multicore, intel stuff, that is. Dec 05 03:22:39 on 2nd thought, nm. Dec 05 03:22:59 i'm not a memory / chip designer. i gotta get to work on my resampler... Dec 05 03:22:59 those cores share an MMU, just like the two cortex-a15 cores on the AM572x do Dec 05 03:25:11 2/5 in fixed-point on a cortex m3 Dec 05 03:25:43 beware of 0 dBFS+ ;) Dec 05 03:26:14 that can be perfectly avoided if you use FIR filters. Dec 05 03:26:26 IIR, not so much... Dec 05 03:26:40 it can be in both case Dec 05 03:26:44 no. Dec 05 03:26:47 it's just more annoying to calculate for IIR Dec 05 03:27:29 i proved about 10 years ago the humble sinc function (which is IIR, theoretically) has no bounds. Dec 05 03:27:44 the sinc function is a monstrosity Dec 05 03:27:59 a crawling horror Dec 05 03:28:00 i think the result applies to any IIR. Dec 05 03:28:03 no Dec 05 03:28:08 prove ti. Dec 05 03:28:09 it Dec 05 03:28:19 a normal IIR filter is 1. causal 2. has exponential decay Dec 05 03:28:24 give me a counter example Dec 05 03:28:30 pick any real-world IIR filter Dec 05 03:28:36 the sinc function is not a real-world filter Dec 05 03:28:41 it isn't implementable Dec 05 03:28:53 neither is any IIR! Dec 05 03:29:00 sure it is, don't be silly Dec 05 03:29:03 pick any biquad Dec 05 03:29:15 why do you think they call it IIR?!? Dec 05 03:29:28 INFINITE ir... Dec 05 03:29:36 yes, but with exponential decay Dec 05 03:29:43 any theoretical IIR Dec 05 03:29:43 so the absolute sum actually will converges Dec 05 03:30:00 just take any stateful filter Dec 05 03:30:20 state += input; Dec 05 03:30:22 output = state; Dec 05 03:30:26 state /= 2; Dec 05 03:30:42 that's a stable filter Dec 05 03:31:09 * zmatt . o O ( it is, right? ... *thinks* ... right ) Dec 05 03:32:07 that's a pretty from-the-hip analysis Dec 05 03:32:22 a strict proof would probably require a good amount of real analysis... Dec 05 03:32:36 analyze it, if input samples are limited to [-1,1] then state is limited to (-2,2) Dec 05 03:32:40 and the specific z-transform. Dec 05 03:33:00 analyzing filter stability is not hard Dec 05 03:33:20 i don't think stability is the issue here. Dec 05 03:33:47 sure, just look at the poles in the z-plane Dec 05 03:33:59 the only thing that can throw a wrench into things is limited precision Dec 05 03:34:19 yes, there's that. including fixed-point implmentations Dec 05 03:34:32 for the filter above it's still easy to see there's no problem Dec 05 03:35:54 if you limit the input range by shifting right by 1 bit then the calculation will never overflow, I think I dare to assert that without grabbing pencil and paper to verify it :) Dec 05 03:36:43 ok maybe I'd want to check what happens for MININT just in case, but other than that.. :P Dec 05 03:37:22 the point is the impulse response is [1, 1/2, 1/4, 1/8, 1/16, ...] Dec 05 03:37:38 summation will converge Dec 05 03:37:43 (specifically to 2) Dec 05 03:38:14 same is true for any stable filter Dec 05 03:39:04 (that's not an if-and-only-if, the sum can also converge for an unstable filter) Dec 05 03:39:15 (I think) Dec 05 03:41:36 but it's funny you figured out how awful the sinc function is 10 years ago... I discovered the same I think about a year ago, maybe bit more, but it seems there's still a lot of unawareness about quite how horrible sinc is Dec 05 03:42:10 oh, it's nice in many ways, though Dec 05 03:42:17 useful Dec 05 03:42:29 like the perfect D/A Dec 05 03:42:45 * zmatt coughs Dec 05 03:43:49 perfect according to some highly theoretical criteria, and if you ignore the fact it cannot be physically realized (nor even approximated), can cause infinite output spikes for bounded inputs Dec 05 03:44:20 the current output is can be unboundedly affected by samples arbitrarily far away in the future or past Dec 05 03:44:34 some perfect D/A there :P Dec 05 03:44:56 zmatt: please don't speak to me about real-world/implementable versus theoretical. i know the difference, and there is no textbook in existence (for DSP) that doesn't rely on the latter to teach the theory. Dec 05 03:45:33 there is not such thing as a Dirac delta function in practice, either. Dec 05 03:45:43 yet that is commonly used to visualize sampling Dec 05 03:45:53 the infinite impulse train, that is. Dec 05 03:46:35 and i've implemented a whole crap load of dsp in real-world systems, so i know about that too. Dec 05 03:46:36 and equally wrong. the properties of these things are mathematical convenience, which is hardly the same as perfection Dec 05 03:47:00 (note that my background is mathematics, so it's quite something for me to say that) Dec 05 03:47:00 zmatt: we have to part ways, here, then matt. we have a fundamental difference of philosophy Dec 05 03:47:05 perfection is unachievable Dec 05 03:47:28 even more so in a digital system Dec 05 03:47:33 any* Dec 05 03:48:08 yates: I suspect we probably agree on a lot in practice ;) Dec 05 03:59:21 gone... gone are ... whatever. Dec 05 03:59:26 :D Dec 05 04:00:10 So now we need the BBB VoIP code. Dec 05 04:00:34 GenTooMan .. run Asterisk :p I know a guy running a company voip on a Rpi (spew) Dec 05 04:01:23 Hmmm just need to add a decent codec onto a board and poof you have an overpriced VoIP system ... err. :D Dec 05 04:02:32 if you used the cores to do some echo cancellation and such .. be a good speakerphone for voip :p Dec 05 04:03:14 I suppose you wouldn't have to worry too much about IO expansion. POE for power too. Dec 05 04:05:40 incorporate video .. make it slightly interesting :p Dec 05 04:05:41 lol Dec 05 04:09:49 Hmmm 3d character that plays with a virtual handset when it's not busy. When it rings they jump and 'pick up the phone when someone leaves a message' now if you could sync the lips to whatever speech is being given that would be hilarious. Dec 05 04:14:23 now you're talkin :D Dec 05 04:19:36 hehehe Dec 05 04:19:42 sounds perfectly doable Dec 05 04:20:27 Scarily enough it is... so do we have cute girl in tight cloths or ... Dec 05 04:21:13 I can see a lot of interesting models people can get for their phone LOL. Dec 05 04:25:00 also a lot of open lip movement animations are available based on language. this could be entirely too silly to be used for serious communication I'm afraid. Dec 05 04:25:25 down the rabbit hole you go... Dec 05 04:27:47 flush twice it's a long way to wonderland ... Dec 05 04:28:57 lolol **** ENDING LOGGING AT Sun Dec 06 02:59:58 2015