Hey, everyone, welcome back to the Nintendo Prime. We got a late night video for you guys because a patent was discovered from Nintendo that appears to apply to Splatoon 3. And, you know, there's some interesting stuff in it that we're going to talk about. But also, there's a weird look at a switch and something described in a switch that I don't think I've ever seen described. You guys can obviously correct me when we look at it here. So first, we got this from Stefan Tatilo. And this is actually on Nintendo Life. I went here because Nintendo Life did a little digging into it. And it says, Nintendo is always experimenting with ideas. And patents are a very important part of this process. Sometimes it'll file something to do with hardware and other times more focused on gameplay experiences. On this occasion, it's about the gameplay side of things with the latest filing, apparently focusing on improving mini-maps. The gist of it, according to Axios' Stefan Tatilo, is that it's about making better mini-master series like Splatoon. And then he shows up this image, which clearly looks like Splatoon. And I can tell you right now, this patent's very much built around Splatoon and Splatoon 3. It mentions paint and inking several times in the patent. Anyways, we're gonna take a look at the patent in a moment because there's one other interesting thing I wanna note besides what the patent's mainly about. And so it says, it's a huge wall of text because patents are and they're very confusing to read through. There are various references to shooting ink and painting areas with ink throughout the patent, which means it's probably something to do with the upcoming Splatoon 3. Go Nintendo provided this summary. It says, this mini-map approach aims to make it easier for players to understand not just their own position, but the position of helpful items in other areas important to the map. The camera will shift dynamically based on moment to moment action, as well as with changing areas of importance on the map. So there's changing how the mini-map and how it works to help structure for players and even for commentators. But when we go look at the actual patent itself, and this is the patent, what I found interesting is, having looked at a lot of these patents for various games, including things like the Breath of the Wild patents, Breath of the Wild 2 patents we looked at last year, is the system they're referencing. It's this, which looks like a Nintendo Switch, except it's got the rounded controllers. And having looked back at other patents, including the Breath of the Wild ones last year when they were talking about the controls and stuff on the Switch, they have a picture of basically what looks exactly like a Switch. This does not look exactly like a Switch.  It's just the design choice of whoever drew this particular image for the patent. And I could hear you on that, but there's a part in here that mentions something very strange. So you go into the game app, or at us, and you get the internal storage device, main memory, communication section, operation section, display section, onto the processor, and then inertia sensor, which says 117. Let's see if we can find 117 quick to see what 117 is describing exactly this good pass. You can see some of these other images. By the way, I don't want to just zoom past images here. You can kind of see images of stuff happening and how the camera's gonna move. And that's cool. A lot of this isn't gonna make a ton of sense until we play the game. But what I find interesting, obviously, is that 117, talking about that inertia sensor, I find that to be very strange because there's no such thing as an inertia sensor in the current switch. It doesn't exist. The motion controls are handled, you know, like at first I thought maybe it was motion controls, but those are handled by the Joy-Con. So inertia sensor. So let's see if we can find 117, scrolling on down. So we got 60, let's see here. See if we can find 117 listed anywhere, which it can be very hard to find 117. You know, maybe we can, I don't know if this is gonna work on a PDF, which of course the search doesn't work for. So finding the exact 117 on a figure can be pretty difficult in patents.  So anyways, what I wanted to point out was obviously this inertia sensor being part of this. And how weird is this? There's actually multiple mentions of the inertia sensor in this patent. And as far as I can tell, there is no inertia sensor in any of the Nintendo Switch patents. So this does make me wonder of course, is this a potential, like, I don't wanna say accidental, but like a first look at possibly what could be a next switch. Again, I'm not telling you that a brand new Switch is coming up with Splatoon 3. That's not what I'm saying. But there could be a unique functionality of that inertia sensor that might have an extra functionality in the game for whenever the Switch comes out.  I'm just pointing out what I'm seeing, okay? If I'm wrong on all this, that's totally fine. I'm just speculating based on my very hard look at patents over the years for Switch. So you guys don't know what you think about this. Obviously, if you're excited about the little bit of Splatoon stuff here, or if you're excited to figure out what the hell is this inertia sensor? And why haven't we seen this listed in other Switches? And why the hell do we have a rounded edge switch on the controllers that doesn't match any of the current Switch designs? I don't know. You guys let me know if I found something here, or maybe I'm just a little bit crazy, probably a little bit of both. All right, guys, I'm Nathaniel Ruffijans from Nintendo Prime. Thank you for tuning in and I'll catch you in the next video.


Okay, so let's look at the simulation results. And by the way, there are a number of experiments that can be performed using EDGCM. One of them is the doubled CO2 experiment that we just talked about, and you can see how there are various settings. You can tell the model what component, what ocean model to use, a mixed layer model with a parameterization of heat fluxes, or a simpler model. If you choose to do so, you can change how vegetation and topography is parameterized. So there are lots of different settings in the model that one can change. And there are various pre-determined experiments that you can just run off of the main menu in EDGCM. But if you liked, you could design your own experiment. You could set all these settings to use the particular version of the model that you want to use. You could specify exactly how to change forcings, whether they be natural forcings like CO2 or other anthropogenic forcings, methane and CFCs. You can change natural forcings like solar output or even the Earth orbital geometry changes that we know are important on very long-time scales. So there are a variety of experiments that you can perform. And a number of the sort of pre-determined experiments are indicated here. You can simulate the last ice age. You can simulate snowball Earth. We've alluded to the fact that in the past there were periods in Earth's evolution where we believe Earth was entirely frozen. And you can do that snowball Earth experiment with EDGCM. But we're going to continue to analyze this CO2 doubling experiment that we were running. And we will look at the output now. As you can see here, we'll do that in a moment.


So, in our last lecture we were looking at interpolation, interpolation polynomial, we also looked at cubic spline interpolation. So, I talked about piecewise polynomial interpolation towards the end, but let me explain a few things before I move on about piecewise polynomial interpolation, we have this function u z and we know values of this function at different points and then we wanted to fit a polynomial that passes through each of these points. So, one possibility was to develop a very high order polynomial which passes through each of these points. So, that would be a continuous function passing through each of these points. There is there are other options as I said that finding out coefficients of a very high order polynomial higher than 3 or 4 becomes an ill conditioned problem difficult to find the coefficients. So, we resort to what is called as piecewise polynomial approximation and one particular type of approximation I talked yesterday. So, if I want to develop a piecewise polynomial approximation what is the simplest piecewise polynomial approximation? Well not cubic the simplest one will be linear line you know. The simplest one would be just a line that I could develop a line that connects these two points then another line that connect these two points. What is the problem with this? This is fine in some cases this works this is useful I am not saying this is not useful, but this approximation piecewise linear approximation is not is not differentiable at the boundary points it is not differentiable ok. So, it is continuous, but it is not differentiable. So, that is why we want to have higher order approximations we could then think of approximating this using second order that is quadratic equation. So, each one of them instead of a line can be a quadratic equation ok. So, this might be and so on. Now, if you are fitting in general you could fit kth order polynomial say quadratic cubic fourth order we normally stop at cubic and among the piecewise polynomial approximations the approximation for which we match derivatives up to k minus 1. Suppose you are fitting a kth order polynomial between each segment and you match the derivatives up to k minus 1th order then that is called as a spline approximation ok. So, cubic spline when I say cubic spline that is because we are matching first order and second order derivatives polynomial order is 3 first and second derivatives are matched for smoothness purpose. So, that is why it is cubic spline normally we use cubic spline because beyond that it is not worth fitting higher order polynomials beyond cubic many times suffices for most of the applications. So, you can very well develop piecewise linear approximation piecewise quadratic approximation piecewise cubic approximation ok. So, depending upon what is your you know what level of smoothness you need in your application in some cases differentiability is not so important you can have piecewise linear ok. In some cases differentiability is important. So, you should have higher order polynomials and match derivatives and so on. So, this is a small point. The next point that I want to make here is that when I am developing this when I am developing this approximation is it necessary that I only do a polynomial approximation it is not necessary that I only do polynomial approximation I can do function approximation ok. So, in general my approximating I mean this is just we are not going to use when we do boundary value problem discretization or when I develop this orthogonal collocation method I am not going to use function approximation this is just a side note that well I am using the word approximation function interpolation function interpolation we will be using approximation in a different context. Just like I can do polynomial interpolation I can do function interpolation. So, in general let us say I have this you know I will just slightly change the notation you have this uz here and till now we were looking at polynomial approximation which means we said that pt is alpha 0 plus alpha 1 and then this was the initial Lagrang interpolation and then we know this values of uzi is equal to ui we know these values at i going from 1 to up to n plus 1 we know values of ui and then we wrote n plus 1 equations in n plus 1 unknowns and then we had a you know simple way of finding out alpha 0 alpha 1 by matrix inversion this we have discussed earlier it is not necessary that I approximate only using or I interpolate only using polynomials not approximate I interpolate approximation will come when you approximate boundary value problem right now interpolation is something in which you try to construct a function that passes through every point. So, this is a polynomial function that passes through every point here passes through every point now I could also develop say another function g sorry not t here gz this is a function of z not of t I could develop another function which is interpolating function and I would call this as some beta 1 f 1 z plus beta 2 f 2 z let us let us let us keep the notation similar. So, let us call this beta 0 f 0 beta 1 f 1 up to beta n in general I need not I need not approximate using simple I need not represent this polynomial using simple polynomial functions I could have more complex functions appearing here. So, this is called function interpolation each one of them is a function of for example, for example, I could use some of the standard polynomials say Lijandra polynomial here or I could use shifted Lijandra polynomial depending upon the context you could use different kinds of I could use here sin n cos I could use here sin n cos.  So, I have n plus 1 equations in n plus 1 unknowns what are the unknowns here beta 0 beta 1 up to beta n these are the unknowns these functions here f 0 f 1 interpolating functions I have chosen them I know these functions like sin cos or whatever you choose I am chosen these functions I have chosen these functions. So, I can substitute values of z and find out the value of that particular function. So, here this would be known this would be known because I have chosen the function I can evaluate the function at a particular point and you know I can then write this into the standard form because this will give rise to you know u is equal to a matrix into theta where theta is nothing but beta 0 to beta n this vector theta is beta 0 to beta n a matrix will have what will a matrix have all this f 0 z 1 f 1 z 1 all these values of this this a matrix is known and then you can find out you can find a interpolating function you can find a interpolating or this is called a function interpolation function interpolation. So, this is a special case of function interpolation you have chosen a special function which is simple polynomial, but that need not be the only way to construct interpolating function you can do in general function interpolation. So, interpolation is if you look at textbooks on applied mathematics you will find much more material on interpolation interpolation right now my interest is in discretizing a problem. So, I am going to restrict myself to whatever I need for problem discretization. So, my aim is now to convert a boundary value problem or a partial differential equation into a set of either algebraic equations which have to be solved simultaneously or in some cases it could be differential equation that need to be solved simultaneously. We have seen several cases right what is going to be different here is how we approximate the derivatives what was the key in the earlier case when you use Taylor series method the key was approximation of first order and second order derivatives. So, interpolating function or interpolating polynomial is going to be used for approximation of local derivatives. So, the word approximation comes when you start discretizing not when we constructed interpolating polynomial. So, the trick is going to be same I am going to develop some what did we do when we developed finite difference method we started with Taylor series we looked at a point right and we said local derivative of this particular local derivative of this particular function can be approximated using Taylor series expansion and then we had this forward difference backward difference formula for approximating the local derivative at ith grid point we divided the entire domain into number of grid points right and then at a particular grid point ith grid point we had a way of constructing local approximation of the first derivative and second derivative. Same thing is going to be done here I am going to use this interpolating polynomial to construct local derivatives approximation of the local derivatives at the grid points at the grid points. Now, just look carefully at the development because this is something which is new for you for most of you and somewhat different from you know finite difference in some sense you know is covered when you in your undergraduate in many cases many of you would have visited finite difference, but orthogonal collocation probably is not part of typical undergraduate program. So, now let us start looking at how we develop this orthogonal collocation. So, I have this so this is again this is z is equal to 0 and then this is my z is equal to 1 I have this similar notation. So, this is my z 1 this is my z 2 this is my z 3 this is z i in a domain 0 to 1 well this domain appears in the context of let us say a boundary value problem. So, let us rewrite our boundary value problem again. So, the general boundary value problem is so in the domain 0 to 1 I want this differential equation to hold actually at every point, but when we do discretization we will end up forcing this equation only at certain grid points the same way that we have done for finite difference and then I have this boundary conditions f 1. So, I have two boundary conditions and I have this second order differential equation I need to develop approximations for d 2 u by d z square d u by d z and then at a particular point let us say ith point I want to develop local approximation for the derivatives and now the way I am going to proceed is let us denote the value of the solution at these points as u 1 u 2. So, basically the same idea where we had said that u i is equal to u of z i well u is the dependent variable here the solution of the problem it could be temperature distribution it could be concentration distribution whatever is the problem at hand. So, this is this is by solution now the trouble is trouble is in when you are solving a partial differential equation and when you are trying to develop an interpolation polynomial you do not know these values u 1 u 2 u 3 up to you do not know these values. So, the trick is use interpolation polynomial together with this differential equation to find u 1 u 2 u 3 up to u n plus 1. So, when I begin the development I am going to develop everything in terms of u 1 to u n as unknowns now let us see how we do this. So, now what I am going to do is my approximate solution to this problem I am going to represent as a polynomial as a interpolation polynomial.   So, you would write all these equations I will write all these equations u 1 u 2 up to u n these are the values of these are the values of this solution approximate solution at the grid points right now I have not talked about how to decide this grid points in this context they are often called as knots or collocation points they are not really called as grid points just a matter of terminology they are same as grid points they are often called as collocation points. So, these points here will be called as collocation points. So, now I can write this and then I can I can put this into the standard matrix form 1. So, these equations n plus 1 equations into n plus 1 unknowns I have transformed into a standard matrix equation. Now, there is a trouble here in normal interpolation when it is not connected with a differential equation you are given some values of the function at the grid points. So, in normal polynomial interpolation you know these values you know these values now I do not know these values right now does not matter I am going to do play some tricks first of all in this equation I do not know 2 things I do not know alpha 0 alpha 1 2 alpha n I do not know u 1 2 u n plus 1. So, both I do not know. So, I cannot really solve this problem and find the solution that is not possible the solution is tied up with the differential equation. So, we have to go to differential equation to get these values but what I am going to do here is let us call this matrix as a matrix this vector as theta vector and this vector here as capital U a theta equal to u. So, this my equation is a theta equal to u. So, I am going to transform this equation and write theta is equal to a inverse theta is equal to a inverse into capital U capital U is this vector U n 2 u n plus 1. So, what I have done is I have said that this set of unknowns can be represented in terms of this set of unknowns. Let us leave here and then let us continue with the next part. Now, let us come to i th i th collocation point.  Everyone with me on this I am going to write this in slightly different way I am going to say that this is 0 1 2 I am going to write this as a inner product of 2 vectors 1 vector is 0 1 2 z 3 z square 4 z cube and so on. So, this has been written as inner product of 2 vectors dot product of 2 vectors so far so good. So, now we need so here now this first derivative is actually. So, this is d u by d z is equal to 0 1 2 z n z raise to n minus 1 into theta into theta we agree with me because this is the theta vector this is my theta vector. So, this into theta vector which is same as 0 1 2 z into a inverse u I am just replacing theta unknown theta are not so convenient for me to work with I am going to work with unknowns u 1 to u n plus 1. So, this is a known matrix a is a known matrix I have chosen the collocation points so I can compute a matrix I can compute a inverse. So, this is a known matrix to me now this multiplication of this vector into this matrix I am going to denote it by see this is a vector this is a row vector this is a n cross n matrix n 1 n plus 1 cross n plus 1 matrix and this is a vector which is 1 cross n plus 1. So, multiplication of these 2 this vector row vector into this matrix what will it give you another row vector I am going to call that row vector as I am going to call this row vector as s i s i is the ith row vector or the row vector associated with the ith collocation point. So, I have represented one minute so there is one more step in between one more step in between we have to do. So, this is the general expression for the derivative now I want to find a derivative at the ith collocation point. So, how will you find out? So, here you will have to put z i so d z i by d z 1 2 z i where is to n minus 1 into a when I want to compute the derivative at the ith collocation point I am just going to substitute for z equal to z i I will get this expression a inverse u. Now, this quantity I am going to denote as s i that is 0 1 2 z i into a inverse this is my row vector this is a row vector what you get here is a row vector.  So, the derivative approximation derivative approximation at ith collocation point is this vector times u what is u? u 1 2 u n plus 1 u 1 2 u n plus 1 likewise I can develop my second order derivative can you do that.  So, this would be 0 0 2 0 second derivative will give you only 2 then 2 then what you will get 6 z into n minus 1 z raise to n minus z raise to n minus 2 am I correct. If I write it in terms of into theta but what is theta a inverse u so a inverse u I am just skipping in between steps they are very simple same derivation as previous derivation for the first order derivative. So, I am just directly writing the final form here you will get this vector and you will get this a inverse times u when I want to compute the derivative at ith collocation point. So, I would just substitute d 2 u by d z square by d z


This is a special video asked for by one of you hard-working freedom family members, and it is a frequently asked questions number one that is asked in Skype right here. I will answer these questions, and if you have questions for me that you would like me to answer, ask me in the comments below. So here are the questions. It is about a short essay interviewing me, and it was originally written in Dutch, but it's now translated to English. So here are the questions. Could you describe how you came to your current job, George? Could you explain what your activities are in your current job? Where do you get your motivation from for your job? What makes a good entrepreneur or professional in your opinion? And what is your experience with time management? Do you have any tips? Finally, what are your tips for beginning entrepreneurs professionals? Let's answer them. First answer, I founded Freedom after we raised 375,000 US dollars to start a new YouTube network on December 1, 2013. That's how I came to my current job. My activities are, I am the CEO, and I make the George show. What you are watching right now at youtube.com slash freedom. Where do you get your motivation from for your job? So this is an excellent question, and I want to ask you as well, where do you get your motivation from to make YouTube videos? Tell me in the comments below. I want an answer from each of you. Since I'm giving an answer, you need to give an answer as well. All right. I am a YouTuber just like all of our partners. Putting myself in the shoes of our partners, what I do is what I would expect of the network I am partnered with. So I do it happily. And I love seeing people grow towards their dreams of becoming full-time content creators that pay all your bills. I think most of you are doing this for that reason. You want to make videos or live streams full-time, so you don't have to do the job you hate. Instead, you could do this job that you love. Am I right? What makes a good entrepreneur professional in your opinion? In one word, execution. Yes, a good entrepreneur needs vision, business savvy, a strong team, money, and good market timing, among other things. But none of that matters unless he or she can get things done, i.e. execute. What is your experience with time management? And do you have any tips? My time management is terrible. My tip is to pick a time management tool like a sauna and always use it. Now, why don't I use the sauna? Well, I just haven't. I don't have a good excuse. But my time management is terrible because I rely on so many different things.  It would be nice to have it all centralized in one place like a sauna. And I hope to do that one day. What are your tips for beginning entrepreneurs and professionals? First, most important, find at least one partner who you trust completely, who can get things done, i.e. execute, and who shares your vision. If you can find one or two or ten people who do all three things, then get started. Everything else comes after that. Now, some people will say, create a solid plan. Plan is good. But many people over plan. You can't really predict the future. The best thing is to create a short plan and then get started and then adjust your plan based on what happens. You never want to try to plan a month or ten months or like too long because inevitably your plan will change anyway as you start executing. I hope this helps. If you have other questions you would like me to answer. If you want to interview me, ask them down there in the comments below. If you have more than one question, uh-oh. That's my alarm. I have to stop now. I'll finish the sentence. If you have more than one question, put it in the same comment so I can answer them all at once. Don't put multiple questions across multiple comments. Edit your comment. If you think of a question later, go back to your original comment, click edit, and add your additional questions. That'll make it easier for me to answer all of your questions. That alarm said, I need to go home and bring my girls to school. It's actually 5 a.m. here in the Philippines, 5 a.m., and that's the time my 7-year-old and 5-year-old have to get up and get ready for school. Why so early? Because they have a school bus that takes them to the school and their school actually starts at 7 a.m. That's crazy. I've never, ever started school even when I was in university at 7 a.m. That's how they do it here in the Philippines. So I have to run. Who am I? You already know the answer to that question. I am George, CEO and founder of Freedom. I'm wearing my freedom shirt today. Woohoo! And I am also George Sunpai, Papa George, and many other names. You, the beautiful family has given me, and the only thing I don't want you to call me is late for dinner.  Old joke, sorry. If you like this video, click the like button down there and subscribe to Freedom Central, youtube.com slash freedom, home of the George show. I am George and you've been watching. Click that I to partner with Freedom and join the Freedom family so we can all grow together. You get many perks like position music. You also get epidemic sound, a lot of other access to royalty-free videos, sponsorships, and many things to help you grow. Just click the links down there in the description below to get involved in our community, our forums, our discord chat servers, meet our graphics team, meet our community team, all of that on discord and the forums. What are you waiting for? Get started. And we will grow together as a family because this is the Freedom family. You are part of it. We are all part of it and we're all growing together. So grow with us and partner with Freedom. That play now button right there on the video bar is all you need to click to get started.


Just five years after the Ikea Illumina tailings dam failure in Hungary, similar images of communities flooded by contaminated mud would appear in Brazil. The failure of the fundal tailings dam would release 43 million cubic meters of iron ore tailings over an area of 668 kilometers of water courses from the Dolce River to the Atlantic Ocean. It would be known as Brazil's worst environmental disaster and would hold a mirror up to the country's mining industry but sadly lessons wouldn't be learnt quick enough. As such I'm going to rate this disaster here eight on my patented plain difficult disaster scale but only here five on the legacy scale as well we'll get onto that a bit later on. The Germano Mine Complex is based in Mariana, Minas, Giraes, Brazil. The site operated by San Marco SA which is a Brazilian mining company founded in 1977. The company is a joint venture between Brazilian Vale and English Australian BHP. The tailings dams in question at the site were used in conjunction with iron ore mining. An industry which for every usable ton of iron ore concentrates around 2.5 to 3 tons of waste tailings are created.  Whilst we're here let's look at the process that creates this much waste product. Iron ore is vital in the production of steel obviously a massive important material for building of pretty much everything. The old one's mind is run through a process of crushing grinding and classification. During this waste materials such as sand and other undesirable matter are screened and either run through crushing again or sent to tailings storage areas. The process continues during concentration of the ore where it is hydro cyclone to separate out slimes and a removal of silica. The separated slimes are also sent to the tailings storage. Once the iron is taken out it is floated and magnetic or gravity separated before being filtered after which it is dried and turned into pellets for use in the production of steel. But that is a really brief explanation and the process is far more complex in reality but let's get back to the main subject of the video the tailings and its disposal in the form of storage. Tailings ponds are useful in draining away the moisture from waste products which then they can be stacked on top of another allowing for relatively efficient use of space. The Germano mining complex was no different and it employed this type of storage for its own waste created on site. The tailings storage area was started in 2008 and was intended to contain a total of 79.6 million cubic meters of fine tailings slime and around 32 million cubic meters of sandy tailings over a 25 year lifespan. The two types of tailings had different properties and as such had to be managed individually which greatly influenced the design of the dam. The sand deposits were transported in a slurry and consisted of silt sized particles which allowed water to drain away rather quickly after being deposited but were not the most stable as they were loose and easily displacable. The slimes were also transported as a slurry but were more compressible and permeable compared to the sand. The design of the tailings was a drain stack variety. The concept was to progressively stack the sands behind a starter dam with the slimes retained behind the sand stack. The starter dam would be raised on top of the sands using an upstream style construction once structurally stable. The area of the sands between the dam and the slimes is rather aptly named the beach. This type of dam has one big flaw and that is the fact that the structure is lifted and built upon the uncompacted sand which if not monitored and maintained properly to keep dry can result in disaster. To prevent static liquefaction three methods were used in the design. First was the comprehensive drainage system underneath the starter dam. The second was concrete drainage channels under the left and right abutments and finally keeping the beach at around 200 meters to prevent moisture from the slimes undermining the foundations of the starter dam. It is thought that the allowable height increase per year is around 5 meters but the dam at Fundow would be a victim of its own success. As stated earlier the project was to last 25 years but by just seven years after its beginning the dam was holding back 56.4 million cubic meters more than half its expected capacity. But throughout its life the dam was blighted with issues relating to drainage construction defects resulting in water management errors and saturation of the sand tailings. An internal erosion event happened in 2009 and the intended 200 meter sand beach width was not being adhered to with slimes getting as close as 60 meters from the dam crest during 2011 and 2012. After structural failure of the concrete gallery beneath the left abutment emergency measures were implemented in 2013 it was decided to realign the dam on the left shoulder by moving it behind the section of the gallery to be filled with concrete. This brought the crest closer to the slimes which would reduce the structural integrity of the dam. Originally the realignment was only to be for a short while but would continue until 2015 which leads us on to the disaster. At around half past 3pm on the 5th of November 2015 a leak was discovered on the dam. Attempts to produce the water level were not effective as failure occurred around 50 minutes later. Around 43 million cubic meters of tailings were released down the Santarium river valley. The toxic tidal wave which was 10 meters at its highest overflowed the Santarium and swept through Benito Rodriguez obliterating the village. The small community was only accessible by unpaved roads and post-disaster rescue efforts were severely hindered. The toxic flood continued down the Gao Axio and Dolce rivers eventually reaching the Atlantic Ocean 620 kilometers down river. The flood killed 19 people displaced 600 families and at least 400,000 people had their water supply disrupted. The environmental impact was truly shocking with around 11 tons of fish being killed hundreds of hectares of forest were destroyed and multiple cultural monuments feeding the brunt of the destruction. All of these effects impacted the local economy and general standard of living for the communities around the area with food and water shortages. Interruption of mining activity severely affected employment in 37 villages and cities and a general ban on fishing and agriculture added salt to the wound. This meant that people had fewer ways to earn money or even get food for themselves. But what was the cause of the disaster? We know that the fundale dam was questionable at best throughout its short working life but what made November 2015 the tipping point? A panel was set up by the Brazilian government to follow Samaco's own investigation into the failure state of the dam. During the investigation documents were leaked hinting that the company were well aware of the structural issues of the modified dam and that collapse was very likely. The information dated back to 2013 around the same time that the emergency realignment of the left abutment was undertaken. The company ordered investigation panel released their findings in 2016 and the failure point is not much of a surprise. It was found that liquefaction within loose saturated sands located at the left abutment started the disaster. This was caused by slimes under the sands weakening the structure due to less than 200 meters between slimes and starter dam. This process eventually resulted in the sands becoming unstable at which point liquefaction was triggered and the dam breached. If the drainage hadn't failed in 2013 necessitating the realignment of the left abutment then the disaster would never have happened which brings us on to the main cause, improper construction of those vital drains. Samaco's activities were suspended after the disaster and were ultimately fined 20 billion dollars which is just under 5 billion US dollars. But that wasn't the whole cost as compensation still had to be paid out to all those affected. This ran the company another few billion dollars. Now I mentioned right at the start of this video that although this was one of the worst it was definitely not one of the last tailings down failures in Brazil. As only a few hours drive away another similar disaster would happen just four years later. This video is a plain difficult production. All videos on the channel are creative commons attribution share alike licensed. Plain difficult videos are produced by me John in a sunny south-eastern corner of London UK. Help the channel grow by liking commenting and subscribing. Check out my twitter for all sorts of photos and odds and sods as well as hints on future videos. I've got patreon and youtube membership as well if you fancy supporting the channel financially. And all is left to say is thank you for watching.


Hi, my name is Vinod Kall and I work for Intel Corporation. I do a bunch of audio drivers for audio DSPs for Intel and today we are going to talk about ASOC topology. This is the kind of work which we did as part of Intel DSPs for latest Skylake and beyond processors. So a bit of history before we go started with this. So ASOC topology is not a new concept. It was actually like three or four years back. Credit score to Liam Goodwood. He started writing this when he was working for TI back in the OMAP days. And in that what we did is basically have a simple DAPM description for a DSP. And that DAPM description was essentially coded up in the user space and sent down to the kernel so that drivers can load this description. In this case, once we started upstreaming it, it is actually not so nice to have the DAPM description in the user space because that essentially exposes all the internal details to user mode. So that's when Liam came to Intel and we started re-looking at this and started cleaning it up a bit and started upstreaming. So initial version of the patches were accepted in version 4.2 and eventually other features made it into the main line and ABI is now deemed stable from 4.9 onwards. The subsequent ALSA lib support was made available in 1.1.0 version of the ALSA library. So why do we need the ASOC topology or why do we need the topology description in the user space? So assuming a simple DSP graph like this one in the picture here, you can have a DSP which probably has two PCMs and two I2S endpoints and between them you can have modules doing the audio processing like say in this example AB and CD doing the front-end audio processing and then on the back end you do the post-processing in ENF modules. Now since it's a DSP, what we get from customers and vendors is oh, you know this is nice but I would like to do something else, something like this where I replace some of the modules in your system by my own modules or by a third-party module which is kind of okay. So I would have initially coded all this particular description in the driver and then when I get the request I would change the description, modify it, put these two new modules inside. Now in a kernel if you do that probably you will probably do a build flag or a module parameter to differentiate between these two graphs.  Then another customer comes and says, can I do this? I don't want this module, I don't want two PCMs, I want only one PCM backend and I want instead of your modules I want some other module called Z. So you go back to the drawing board and say oh, how do I figure things out and try to change the description again and so you do that, another guy comes and says you know what, I need a third PCM probably, I want to do a low latency already buffer application, can you do that for me? So this kind of cycle happens endlessly that you keep on getting requests from customers and you have to continuously modify your graph description because it's a DSP here. Everybody puts DSP for scalability and flexibility purposes and if you're not able to customize it, it doesn't really make a lot of sense. So that is when we started looking at ASOC topology, Liam was working in TI and then we started collaborating and then he came over back to Intel and that is when we started re-looking at it, how do you want to do things? So the way we have done this now is we have a simple description in user space, we call that a topology configuration, then we have some tools which can build that configuration into a binary description, we call it topology.binary and that binary we pass on to the kernel. So kernel loads that binary description and then creates the whole DAPM graph and widgets and associated elements for it. So now as we say in the problem, we had a problem of being able to customize, not able to customize for the customers. Now instead of having module flags, build flags or all sorts of things, we can just simply provide a different configuration file to different customers, they can build it for their own and use that and load it in their own systems. So this way we solved the problem of configuring the system, scalability and changing the graph per user or per vendor for us. So how do we do this? Okay, as I said we described the topology in the configuration file, this is called topology.conf, you can see the sample configuration files in the ulcer library right now. Since we are using it in the user space, we need user space tools and utilities. For this we have our own good old ulcer library to do the job. So we have APIs in ulcer library which can parse this configuration file and build it for us. The syntax of configuration file which we'll look in the future slides is basically the old UCM style. This is what people used for UCM description. For main purpose to reuse the UCM description was so that we don't have to rewrite the new parser in the ulcer library to the parser syntax. We already have ulcer UCM parser. This is built using ulcer utility tools. The ulcer utility provides a tool called topology tool which we saw in the previous slides. So you can use a simple configuration file and the topology tool to build it out. Along with the whole configuration file it allows a manifest. This is just sums up what you are going to do with the configuration as drivers can use it for bookkeeping. For DSPs, apart from the description it is pretty much important that we provide a way or mechanism for drivers to know something more about the particular element or particular widget you are going to do. Typically it might be for let's say a coefficient for the particular module which you need to run at the initialization time of the module or it may be some magic numbers which you would want to communicate with your firmware. So that is not a standard description that is a specific driver specific or firmware or DSP specific description. So for each element in the configuration file we also allow a private data. So for us it has been very useful because we can describe all that what we want to do for DSP and all the magic numbers DSP needs to put that in the private data and send it down to the kernel and kernel can forward it out to the firmware. So what are the information do we have in the configuration file?  So similarly here we will also define the controls like mixer control, enumerated control, or byte control. Byte control is specifically important in terms of DSPs because you would typically have a module which would need a bunch of parameters to be configured. So you can send some 100, 200 bytes to the particular control using byte control and in this case we also did something called as TLV byte control because traditionally also controls have a 512 byte limitation which we can work around by sending it as a TLV type of few kilobyte of data or more. So that is why byte controls are important here. Then we define for the particular graph the DAPM widgets what we are going to create and to link those DAPM widgets we have the DAPM graph associated with them. Then as we saw in the previous diagram in one picture we had two PCMs in another one we had three PCMs. So we allow people to specify how many PCMs you have to use because we believe that for a system PCM is limited just by your DMA channels probably for a given system and then people would want to have multiple PCMs on a system or even lesser PCMs on a system so that is kind of a software concept which should be customizable. So we provide people to specify front end or PCMs and if you are doing some processing from the modem to the codec we specify the configuration for dilings and backends. So how does the configuration look like? First to specify a mixer control we define it by term section control mixer with the mixer name. Mixer may be multiple multi-channel controls so in this case we can define the multiple channels with the channel declaration. The channels can be mono or stereo to be simplified but if in case we have multiple multi-channel control you can define front left, front right, rear and so forth and so on these are all ALSA standard control names. Then if we are in kernel when we define a particular ALSA control with the ALSA control we typically define the callback ops which are basically set get an info callbacks which are called these callback ops can be one of the set of the standard callbacks which are like wall s, w, mixer, bytes, enum, strobe, range we are allowed to define all this along with that if you are in the kernel what you can do is to specify one of your own driver specific callbacks typically we do it with the external keyword when we define ALSA control in the kernel so similarly in this case you can define ops control we'll have let's say info function as my standard wall s, w but in case of get input I want to define my own function so you can define a value here which will correspond to a driver specific value when the kernel loads this control it will try to find the value and associate it with this control so this way you can either use the standard values or your own driver specific values the control always has an axis this specifies how a user mode can access this control which may be a read control a read-only access or a write-only access a read-write access or a TLV access or TLV read access, TLV control access so you can specify what the axis of this control would look like along with this you can specify the maximum values this control can take whether it's an inverted control or not if it's a TLV type of control what is the TLV data associated with it and for DSPs private data second type of control is byte control you can declare that with the section control bytes with the name associated with that particular control most of the things are similar to other control, mixer control type you can specify along with that a byte control whether if it's a DSP in a codec probably you would have a register associated with the particular codec and then you can define what is the register values what's the base, what are the number of registers what are the mask values and what are the maximum values this control can take if it's an enumerated value first we need to define a text section for the enum values it would need to take so that we define using section text with the name of the enumerated values and with the set of the values then you define the section control enum for the enumerated control with the name of the control rest of the things are same but the only difference here in this case would be the text section in this text if you can see we have an EQ1 control which is referring to the particular values you would have given so this way you can define a control which has set of the values and the control itself so this is all about control moving now to Dappam widget a Dappam widget typically you would define in the kernel with a macro and you will pass on set of the values these are kind of similar things what we do here we define a section widget for a Dappam widget with the name of that particular widget and first we define what is the type of the widget the type of widget can be AIF in, out, PGA, ADC, DAAC what else PCM which is a die-in, die-out, input, output these and few more are allowed types of widgets so we define what is the type of the widget if it's a stream widget type you need to associate a stream name with it so you can define using stream underscore name value then the typical stuff what we define in the kernel it's the same thing here as well so is the nopm valid or not what is the register bit, what is the shift, what is the is it inverted along with that there's a control, there's a fail in also control also Dappam widget called a subsequence not many people use it but it's in opinion it's quite useful for the DSP guys if you have bunch of widgets for example PGS and when you want to do a DSP sequencing your sequencing is pretty much defined by what your firmware can do so in this case a firmware is enforcing some rules for the ordering of those for the creation and enablement of that particular widget you can use the subsequence field within that widget type to define what comes first and what comes last so that is where subsequence field for at least for us is pretty important because DSPs can have different kind of sequencing requirements and you can satisfy that with this value then event type what are the types of events you would need so if you have a Dappam widget and you want to have your own event callback for that particular widget this is the value you can use so you can define event types in your driver give them indexes one onwards and then once the kernel loads this particular widget it will try to map that type with this value given here and set that particular callback for event in this widget now for the callback we also have the flags like standard flags pre-pmu, post-pmu, pre-pmd and post-pmd so if you want to specify the flags for which the callback should be called we can set it here and finally if the Dappam widget has a mixer associated with it like a mixer control you can define the mixer name here or if it's an inamirated control associated with it you can define the inamirated control here and in the private data so we have defined the controls now we need to associate them controls all the way into a DSP graph so you can define that with a section graph and as you do in the kernel when you have the Dappam widget same control source you would do the same thing here but it's just a comma separated value if you have no control no need to keep null as we do in the kernel we just leave it blank finally the PCMs so PCMs in this case are of two types one are the front end PCMs and second are the back ends which are basically the i2s ports so first we define what are the capabilities of your PCM that we define using section PCM capabilities with the name of the particular capability here we can define what are the formats this particular PCM can take what are the channels minimum channels and maximum channels we can have for this PCM what are the rates we can have for this PCM once we have defined the capabilities as you typically would do in your driver it's kind of analogues to that we define what is the configuration that particular PCM is allowed to take so for the configuration we have typically two things playback and capture depending on what all you need to support so we define that using section PCM config with the name and then for the it has two sets one is the config playback and another set is the config capture in the config playback you define the format rate channel and if you have a TDM slot you can define the TDM slot as well so you do this same thing for the capture this specifies what is the configuration which is allowed to take you can have multiple capability sorry you can have single set of capabilities for the PCM and multiple configuration so once you have defined these two you can define the PCM the front end will look like something like this which is declared using section PCM ID is the one which is used to bind it to the PCM associated in the driver and then you can define the die name that is the name which will appear when you create the die and you define the playback if it supports playback for this we would have previously defined the capabilities you can set the capability here for this PCM and the configs it supports so you can have one config and multiple configs depending on the use case you need similarly for the capture you would do what are the capabilities for the capture what are the configurations required for the capture now along with that typically we sometimes need to have playback and capture in symmetric format so you can define symmetric rates or channels or sample bits true if they are not true you can set them to false if they are true you can set them to true and associate again a private data which your DSP can use after PCMs we can define die links so die links are something like codec to codec links in the DSP where you are probably getting the data from modem and sending directly to the codec and so forth so you can define those die links in your topology as well so that can be defined using the section link name in this you can have a stream name associated that is the DAPM widget it will be associated with it and you can have multiple hardware configs these are the hardware configs you will apply for that particular die link along with the configs kernel will pick one config which will apply which will be applied for this at the default that you can specify using default hardware config then the usual symmetric rate channel and sample bits if it is true or false you can specify for the die link typically when driver kernel creates a die link it also creates alsa control for it if you have the multiple configuration the config 1 to n in this case would correspond to the enumerated values for that particular control last the back end i2s so one of the back end configuration is actually a bit different here because we don't define the back end as such we define the configuration which can be applied to the back end this is for the simple reason that your front end PCMs are software driven you can define as many as PCMs as your hardware limit or if you can define only one or two based on the uses you want to do on the DSP but your back end are actually limited by what your hardware supports if you have only two i2s ports you can do more than two so it's a hardware thing so that should be enumerated by the hardware you can scan how many ports you have and create your back end links and die links but we allow the configuration to be specified so for example in one particular board you would want to run it at 48 kHz but on a different board you wouldn't want to run it at 96 kHz or 41 kHz so from topology we allow people to specify what are the formats you want to apply for that particular back end configuration so that you can define using section die and then for the PCM playback you define the capabilities for the PCM capture you define the capabilities you would like to have you would like that particular back end to have so we have been talking about private data a little bit more details because this is kind of little interesting for us so how do we define private data so for each of the modules you can use a section data to define private data it can be of multiple types if it's for example a particular binary coefficients for a module let's say equalizer you can define a file where you have all the binary coefficients it can load and set it if it's just a simple byte you can define a comma separated byte value or a word value or this thing shots along with that what we also added is the support for tuples so byte's word shots are fine but they are not human readable that means they are very very hard to change so instead of having these binary values if my DSP needs value A, B, C for a particular use case I want to change those values if I can make them human readable it eases people's job to customize those values for them so that is why we came up with the support concept of tuples we'll explore more in the subsequent slides so once you have defined all the private data you need for a particular module or a particular element you can define section you would have defined as a section widget or section PCM or section mixer control for that we will have the data section in that you can specify all the private data you need it can be multiple data sections for the private data because typically if you have one data section you can have only one type of data so if you have a combination of bytes and shots you would need to define first as bytes and then as words and then add both of them to the data section so what is this tuples all about so what you can define is tokens so it's simple key value pair kind of work what we have done here you can define multiple tokens token 1, 2, 3 and they would mean something which your driver would understand for example for our modules we need to pass a UUID value so one of the things what we do is what is the UUID of this module which we need to send it down to the firmware and we can define a UUID token for that and this is how we code it because tomorrow if somebody is integrating another third party module which has a different UUID they know oh it's a UUID this is how I need to replace it so that way instead of binary byte values or hex values it's simple to customize for user so how many types of tokens we can have first is a tuples string you can define a string which you can pass to firmware or your driver you can define a UUID tuples dot UUID or you can define a boolean value with tuples dot boole or you can define bytes simple byte values you can have multiple tokens for different type of byte values which your DSP would understand using tuples dot bytes or again shots or words similar now we have defined the configuration file we have defined the private data we have defined all the widgets in the configuration file what do we do with this configuration file we build it how do we build it also it has a tool available it's called also our topology so using the minus C option you can give what is the configuration file for this particular system you want to run and with the minus O output would be whatever binary file you need to write this binary file would eventually need to be installed in the kernel so that your driver can pick that up so this particular tool uses also our topology APIs which were defined for this work in this the also topology tool basically uses snd underscore tplg underscore build file API it's a single API which does full job for us it essentially takes this configuration files passes through it finds all the sections finds all the data for the sections and creates the elements for it if you don't like this tool you can write your own tool additional C APIs are available in also library for parsing these API looks like this so first what you need to do is to create a new topology instance this you can do using snd underscore tplg new so it will define a new instance for you and once you have the instance created for all the elements which we saw in the configuration file you need to call snd tplg add objects the object may be control, mixer, byte, enumerated or it may be a die it may be a dapple widget it may be a map once you have done adding all the objects if you want to have manifest block in the file you can do that by invoking snd tplg set manifest API and once you are done with everything you can ask also library to build it out for you snd tplg build by specifying an output binary file and at the end you free the binary so how does the binary look like so binary has header associated with it this header perceives each and every block of data we have in the binary file first we have asock as the magic number so that we know this is our binary file and then second word will be abi file abi right now is version 5 then we also allow people to override and do their own stuff if you want to do that you can specify your own vendor version so that core will ignore it and directly pass on it to the driver if you are not doing that you can define it as one of the standard topology types which we were discussing like control, mixer, widget, tie, PCM so that you can define the topology type field after that there is a field for header size this is typically used to check if you have any abi mismatches if you are defining vendor version you would need to have your own vendor type so you can have use the vendor type field for that and after that if for the particular block what is the payload you are defining so that payload size will be there followed by index and count of this block so this particular header is there it's not just a file header it's a block header so we will have multiple blocks so the binary file will look like something this so you have a topology header and followed by the manifest manifest is always the first block because as I said it's used for bookkeeping operation so it makes sense to tell the driver first what how the manifest looks like then again you have a header for mixer controls you define all the mixer controls in this section together followed by another header for enumerated controls followed by enumerated control data and the header for byte control followed by the byte control data the header for dapm widgets followed by dapm widget data header for dapm graph followed by the dapm graph header for the pcm followed by the pcm and die links and dies so this is how the complete binary file look like so we have done the whole user space thing where we define the configuration we now have built it now we move the gears onto the kernel side what do we do in the kernel so you have this binary file created you install it into the kernel and then driver would pick it up how does driver pick it up we have a nice API call request from where so this is what we use to load the file from the user space into the kernel so your driver would call request from where API once we have the file loaded into the kernel space we pass it to the ASOC course using snd so ctpl g component load so this component load will load the topology file for that particular component the argument it expects is the first is a component it may be a platform component may be a codec component depending on your point of view and then we give it our own topology ops so we look at the ops a bit later and then you give the firmware file which you want to load so what does this API do the topology component load API will start processing you have the file with bunch of things in it followed by the block so it will start to process the headers one by one and process the blocks based on the type it finds first check the valid header did we get bonkers or did we get garbage from the user space so we check we check for the size this helps to detect the magic ABI mismatches or wrong data then the magic number is the magic number right is the ABI version right so when we started we started with ABI one and as I said anything it was a team stable so till four it's all development versions and four onwards we are backward compatible so if you're running five and you have a binary version four it's supposed to work well actually it does and then once we had done we load that particular header once we loaded the header we will find the type of the header and type of the block which is following this particular header and we will invoke a particular function which is specific to the header element loads which we have in next slide once we have loaded all the elements that means our job is done so we mark it as complete if you remember in driver when we define controls or when we defined widgets we create a template for those widgets and only when the card is instantiated then only those widgets are created so similar concept is applied here in the complete if the card is instantiated we actually go and create those widgets if not we just keep the templates at that point of time and once everything is done we call the topology complete it's done so what do we do in the each element load type so in the element load type first is the K control element load this is called for mixer widget and byte control in this as I said we will typically call add K control this is something you can open code and your driver or call the micro which we have and then call sndsoc new for those particular controls if we have a graph type of widget that's the map we call sndtplg dapm graph element load where we will find all the elements in the graph and start to add those dapm routes by calling sndsoc dapm add routes then if we have a widget we will call dapm element widget load and in this case we will call dapm new control for the pcms we will call register the die and add those dylings based on the pcms type and as I said if you have a back end die we will not create the die for that because that's something done by your driver so we will find that die find and set the stream information and the die flags for that as you would have specified in the configuration file same thing goes for the dialing because dialing is again set by your hardware or your driver we specify the configuration so in the link element load what we do is find the die link and then set the hardware format and set the flags for this then in the manifest type we will just do the manifest load and tell driver this is the manifest details in the header we saw that there was a vendor load function and vendor type if at all it's a vendor load or vendor load type then in that case we don't do any handling in the kernel for that or in the core for that the driver is supposed to do it we can't implement it in our driver but if you want such a flexibility or if you have a different use case you can use this this is also the default handler in case driver kernel doesn't recognize the type of it and it will call the driver's load function so how does driver specify the various load functions hold on before that what are the ops topology ops the control has so when each of those widgets have been created or you are invoking TAPM to create widget or PCM or element load for you in that case we had the private data so how does the private data get communicated to the driver so for each of the object we can specify what is the object callback so object callback can be of type control widget die link manifest and complete so for each of the operation assuming you load a control in that case while you are creating that control you are in that particular control context after the creation of the control we will invoke drivers control callback so the driver we know this is the particular control getting created this is the context of this particular control and it can go and load up its private data or save or whatever it wants to do with that particular private data so this is the information for drivers so similar callback is given for widget die link manifest as well as as well as vendor so in the previous slide we saw that once done there is a topology complete callback so that topology complete callback which in turn will tell driver that okay I am done processing with whole topology this is the end of it so if you want to do some step at the end of it you can use that particular hook so how do the IO ops look like so as we discuss we have the control where we can have a standard set of IO ops and if you do not want to use the standard set of your get info functions you can use your own driver function to do the job so that is declared in driver as your topology control ops where you have the id field this id field has to match with the id you have given in the configuration file that is how the core matches this is the particular callback you can specify and you can actually do a mix and match you can specify a separate id for get you can specify a separate id for port you can specify a separate id for info typically its get put would be paired and info can be separate or you can have a standard set for info but you can use driver based values for get input sorry so this is all about topology ops lastly how does the manifest block look like we have been talking about it this is how the manifest looks like you have the sum of all the control elements in it you have some of the all the graph elements, PCM elements dialing elements, dial elements and the private data so typically we use it to allocate memory because we know we are going to get 50 control so lets allocate memory for 50 controls in the driver so that we can keep the driver context for it and in the private data we have a generic firmware specific information we need to load for our DSP so that we can specify in this case here which is not like a particular element type of information which is a global DSP information which you want to know so this way we make our driver more scalable and kind of little more agnostic and independent of the firmware in practice lot of things are still not so great because still you have a dependency on firmware but we try to abstract as much as possible using those values so this was a manifest block what is our future work so one of the things we have today is all the configuration files which we have upstream for our projects they are in the ALSA library which kind of gets updated once in six months so during the plumber's audio conference discussion we discussed that we should separate it out to a separate gith which is just a configuration file where all the UCM configuration and topology configurations are so that they can get frequently updated and picked up by distributions so that work has been started right now from the user space side we only support ALSA library we don't support we don't support tiny ALSA that is something which we need for the non PC use cases to be done so one of the things we have in the widgets was a particular index field so using index field right now everything is zero for us because we load all that at a single shot but what we have the flexibility is to specify different set of graphs using the different set of indexes so you can say I want to load index 1 now and I want to load index 2 for a different use case and index 3 for different use case so you can specify sub graphs not the complete graph in one shot but different type of sub graphs using those index values so this work is still to be done okay that's it from my side any questions that's just a binary file with the format we gave but I've seen that pretty in number one so that is basically for whatever you got the driver we have a default configuration which has a sample graph so that has been compiled into that particular binary file and that is what you are loading in your system so if you want to customize the graph or you don't want some parts of the graph which is probably not of use for us or you want to add more things for your graph what you can do is change the graph compile it and install it so as I said we have this request firmware so request firmware picks up the file from standard parts like live firmware so you would need to again go and install that particular file in your standard directories of your distribution so rather than starting with the binary file you need to go back and start what is the configuration file for that particular platform you are using right now it's in also lib right the Skyler configuration file is already there it will have the links but it will not have the controls defined so the whole graph we don't code it in the corner so without if you kind of just remove the dfw file it will fail to load the driver will fail to load not precisely so if you remove the file the driver will fail now you know okay good so that ui kind of thing yes we have been talking about it but then that will be a vendor specific ui because like for intel we will do our own stuff which understands our graph some other company may do their own so probably there won't be a standard ui associated with ulcer utils which is like for us it's a configuration file which is a standard but on top of that yes there can be a ui and I think we will have some ui in future available for people to use uis are nice right yes so the configuration may not be different a lot but then the private data where the secret source for the particular dsp lies in that is where we need a lot of values to be configured yes yes yeah Sunday patch yeah yeah ulcer live precisely yes yeah that is like what people are looking at that and runtime you define a particular section of the graph and then you say okay load this particular thing yes it's essentially for that purpose only yeah any more questions yes so fix up is nothing but your hardware configurations so if you remember let's go back to that slide where we specified the back end this is the link front end and next to next year you are here defining what your physical die configuration capabilities are so this is your fix a function implementation actually can remove that so right now in the upstream driver we don't actually have die support we have the all widget widget topology because we wanted the whole topology to be done first because that is where the most of the configurability is actually coming from the pcms where the like little later in the game it got upstreamed in only 4.8 ish time frame so pcms support in the driver right now is not there it will come eventually yeah right now we don't have pcms support pcms need to pcms need to be there in the machine driver for your particular machine yeah it's not supported today okay controls widgets dappum graph dappum everything is there apart from pcms okay so if you are familiar with a soft driver it's a simple stick codec driver so what you would do is you would have dappum widget section where you will define all your dappum widgets in a table and then you will have a map table you will have a control table and then when you initialize your particular codec you will register that particular codec with a core and in that you will give it all the values in the table so that is how those used to get loaded and that was the only way to load now we can remove that hard coding from the kernel and put it under the user space and customize it it is not useful for a lot of codec vendors because codecs are typically fixed function so it doesn't change but for codecs with dsp this thing will be useful in fact for one of our earlier like metfield code if merifield code if you look at in the upstream we have the whole graph coded in the kernel and it's difficult to customize and that's where we started looking at how we can customize it differently because I have whole of the graph added in the kernel using the same set of declaratives where we have defined app on widgets, we define controls, we define the map and then we load it always we can't change it so in this case right now we have Skylake shipping on lot of devices and people are doing their own customization for that any more questions? thank you guys


Hello, I'm Omar Fernandez director of strategy and operations and GitLab and today I'm with Mike and Andy Can you tell me where you work and what you do there? So I am the CTO at Chainstarters. I've been at Chainstarters now for about three years. We, you know, we build a platform as a service. It's a development platform and we are tightly integrated with GitLab We have a self-managed GitLab instance and we use it You know, every day we really enjoy it. So yeah, yeah, Mike, how about you? I'm the VP of engineering at Chainstarters and I started just around two years ago first as an intern then as effectively the senior back-end. How much do you personally use the GitLab product directly? And what is your interaction with the GitLab product itself rather than the infrastructure side of things? I spend I would say a good 15-20% of my day doing direct interactions with GitLab Obviously, you know, I'm developing API, developing infrastructure but a lot of what we've built, almost all of our repositories have, you know, our Chainstarters development repositories So the ones that are developed to build the platform itself Those ones are obviously in GitLab and they all have CICD with various levels of complexity What do you feel when you work on GitLab versus if you were forced to not work on GitLab? I feel relief when I work with GitLab. I mean, it's true I just feel that like I've got so much of the, I don't want to say complexity again but confusion, you know, is removed. It's so much easier to reason about The other thing about GitLab that I feel when I use them is I feel like I'm on the cutting edge You know, a lot of times in tech you can feel like you're using something and you know it's outdated I don't have that feeling with GitLab. When I'm using GitLab, I feel like, you know you really are pushing the boundaries in terms of what you think is the next thing that we need and making sure that we get it out soon enough and that kind of stuff How do you feel that you've personally benefited from using GitLab or advocating for the use of GitLab? GitLab itself is a part of my job that I could expect to work on the first time Basically from day one, we haven't had that problem It's pretty comforting in terms of, you know, as far as our clients are concerned the hosting of their code and the way that they interface with those repositories and the functionality that wherever that code is hosted, offers to them is sort of irrelevant insofar as it works It's nice to me that I don't have to worry about it working or not The functionality that GitLab provides at the level of all of the stuff that you guys have built is fantastic It's awesome. I love all that we've talked about, so thank you for taking the time


Two things that we'll test for today is we'll test for total home infiltration, so that'll give us our natural air change of the house, meaning basically how tight is this house constructed. And that's when we put a number to that, and that's what we're going to come up with today. And then the other thing that we're going to test for is actually the amount of air that's lost through the ductwork to the outside of the home. So in this house it's not a big deal, but if you have say like a slab on grade or if you have a lot of ducts that's above your ceiling or even below ground or that sort of thing, then you may be concerned about how much air we're actually conditioning outside of the thermal barrier of the house. Okay, one of the things that we'll look at when we're doing a duct blaster test is that we need to seal off the return air grills. And what we typically do is we'll use a duct mask tape, which is actually an eight inch roll of tape. It's kind of like floor mask, except it's just clear and it doesn't peel off paint or anything like that. It's kind of temperamental to work with, but it's nice to have something like this to tape over the grill. So we tape over the return side and we'd actually tape over the supply grills. I don't know if you can see that or not, but we tape off the grills on the front there so that when we do pressurize the house, we don't have air going back up into that boot. Okay, so we're going to start out at a .7, so we're at a positive .7. And now our fan is actually blowing air. Just to start spreading those turbo blowing air into the house. With all the registers being taped off, all the return and supply and that sort of thing, then we can go back and we can look at the duct blaster downstairs to see how much air we're actually losing from inside the house through the duct work to the outside. Right now we've got this on a five second average along with the blower door. It's a five second average. So we're reading at 25 pascals, positive pressure on the house. And with everything taped up, the air that's actually moving from the house to the outside of the building is now being monitored through this duct blaster. And so when we turn on our duct blaster, when we get to a negative reading here, we should be able to just touch it up. And right now it's showing that it's losing about 10 CFM. And like I said, it's going to jump around a little bit. Right now we're seeing about 25 to 28 CFM to get us back to a base pressure of zero in the house. But that done, that's really all we need to do with this. The rest of it is all blower doors, so it's all infiltration testing, which means the next step would be on an energy rating for houses to depressurize the house down to a negative 50 pascals. And so we'll go up and do that next. So right now our fan is working, so it's blowing air from inside the house to the outside. You let a blower door run for five, 10 minutes, then you can actually walk around the exterior of the building, all the exterior walls. And that's when you're going to start seeing some leakage come in that you can pick it up with a thermal camera. If we were going to look at depressurization, we can look at the ceiling. And we can see that the ceiling is nice and warm. We can see all the trusses in the ceiling right now. You can move down to the walls, and you can see actually the studs in the walls. Studs in the walls don't actually, wood doesn't hardly have any r-value to it. So what happens on this thermal image is that you'll see the cold coming through transferring through that wood stud. And then in between each stud is where we have the batting, the fiberglass insulation. And you can see that that area is warm, and then each stud has that cold thermal bridging come through it. So, and that's just heat transfer basically. Probably has a little bit of infiltration, but that's typical on a sliding glass patio door. All in all, the house looks really good.