 Okay, welcome back. Today is January 4, 2021. Happy New Year, everybody. This is our first DevSync of the new year. We're going to catch up on things. We had the last week off, and so I don't expect that they got everything done, but we'll see. I know that I was busy ordering parts for the Mark II DevKits, and those have all been placed. We've got all the parts flying to and fro to the various places to be assembled, and those are on track to get done by the end of this month, which means that we should be able to ship them in February as planned. So I think that's a good start for the year, and let's check in with everyone else here and see how the things are going. Chris Fair. Yeah, so today I worked a little bit on getting my new materialized view integrated into the code, but most of my time today was spent back and forth with Ken looking at this microphone issue on the Pandacore build. We get closer and closer all the time. Now, and Ken can probably give you some more down to the NITS details, but it's down to basically when we try to read from the microphone, that read call from the microphone is failing, and we think it has something to do with, well, I think it has something to do with the settings, like the sample rate and all that good stuff, but as Ken will mention, basically, the configs are the same as they are for the QT build, as they are for Pandacore and the QT build works. So I had the exact statement in our code where it fails, but that statement goes out, basically pulse audio and port audio and does things kind of low level. So like I said, we're closer than we were, yes, on Friday or Wednesday, whatever, Wednesday, but we're not quite to the smoking gun yet. So I will continue to do whatever I can to help Ken poking through our source code and through pie audio. And Ken is doing some more of the lower level stuff. So I'll continue to do that and hopefully we'll figure out what's going on here and get our microphone fixed. All right. Great. Thanks. Yes. Yeah, so I guess to extend on that a little bit, there is a patch that has been released by an open source patch that Ken tested out first and Pandacore applied and said seems to be working well for them. So it doesn't actually fix the issue, but it handles it. It handles the error more gracefully. So there is that, at least there was also the issue where the precise download would time out got pegged down to because they're using squash FS first read of any file basically is a bit slower until it unpacks it and cases it and stuff. So when micro first boots and it tries to hash a really large binary file, that takes a long time and times out. But anyway, so we've increased the time out on that temporarily, but I'm still the firm believe that we don't actually need to do that, because we should just be shipping the precise binary and not trying to download it on the fly. Yeah, so what's involved in, I mean, I think we can make that call I don't see any reason to. I mean, I certainly agree that that binary file should be part of our build and not part of should be considered data should be considered code right so it should be subject to update the update process and not, you know, anything else. So what's involved in packaging that up and making that part of our. So it's already, it's already packaged up. The problem was, like, because when you intuitively when you package it up you just you just include the binary right, but because of the way that we download it, it needs the table with it. Otherwise, it doesn't think that it doesn't think it exists because it checks the chart, it checks the table rather than the actual engine itself. And so that was also the model. Yeah, anyway, so so at the moment, we're just packaging up both the table and the extracted binary and the table and the extracted model, which we shouldn't need to do. And so then I'm also doing some work with okay to, to change that process a little bit so that it no longer requires that table to be there, which, you know, slims down the whole thing a little bit. And everyone in the community seems pretty happy to to pull that out. We may, there's also the precise plugin, you know, we can move directly to a precise plugin if we want to. But yeah, but both things aren't too much work. Well, the plugin seems fine, but it wouldn't. Yeah, it seems like you still need to solve that issue because you don't want that issue to become part of the plugin. Right. Yeah, totally. Exactly. Yeah. Okay, well, I'm all in favor of fixing that because it sounds like it's a mess and let's just make it clean. Yeah, I'm not really sure why it got done that way when nothing else that we do works that way. Well, the skills are worked that way because every time it boots up right now it goes out and tries to update all the skills. Yeah, I remember that right. So I'd love to blame some. Yeah, anyway, so I did a bit of that. I did some more D bus investigation, very, very small amount to train to wire up the Wi-Fi screens. Open voice OS is now using our new Wi-Fi connect skill or fork of it anyway. So that's that's cool too. And yeah, I was mostly responding to Kickstarter backers and stuff catching up on emails from the holidays and that sort of thing. But yeah, people are generally, generally pretty excited that we're finally shipping dev kits. There's a few mentions of like, you know, here we go, Chinese New Year is going to be the next thing that jumps in our way. But I hopefully not stupidly assured them that we'd accounted for this and that if we come out in a month's time and say Chinese New Year screwed us, then they have my personal blessing to point and laugh and ridicule us. Yes, we're Chinese New Year. And we're getting stuff all done before that happens. Yeah. Anyway, that's me. Okay, Derek. Yeah. So today I've been working a little bit on double checking stuff on so I cut a couple more laser cut enclosures, put them together. Feel good about it. I've kind of handed that off to Chris and Josh to do purchasing. I think they're on it. Josh gave me the thumbs up. And then a little bit this afternoon, trying to figure out how to get things to China. This has been some new added hurdles for shipping to China that I've discovered the EEI requirement that you have to file to ship to China. So our boards, we've got to send some consigned parts to the assembler. I'm still actually, as we speak, I'm kind of working on and trying to figure out how to do this, maybe through DHL, because I did not have success at FedEx. So yeah, that's a bummer. I need to get that, you know, hopefully I can still get that out today. Johnny's helping me too if I didn't mention that already. So yeah, that's been my day so far. Great. I just want to mention for everyone who's questioning or concerned about this, the parts that Derek is talking about are actually optional parts. They're something that we're testing out, but they're not required for the for the dev kits. So we've got a little experiment going on and we want to see if the PCBA factory can solder these onto the boards better than we can do by hand. So anyway, it won't impact the dev kits shipping. I need to imagine, given that the chips are sourced from Fort Meade, Maryland, that it would be easier to get them out of the country, but apparently not. All right, Ken. Last but not least, well, I guess we haven't done Josh yet. Anyway, go ahead, Ken. All right, so where to start. So I created a what I would say is leave precise alone for now. It's one less moving part. We want to get this build and this image working. And it works as is. I mean, it's it's not that bad what it does right I mean it looks at the tar and it takes the checks some of the tar rather than having to take the checks of the entire binary. You know, and it also does the same thing for the model downloads them on the man. Now I suspect some of the problems we were seeing earlier. Had to do with some of the stuff that's coming out from Panicor and again I don't know their boot or build process of some of the stuff just comes to me piecemeal but it seems like they're unzipping some volumes on boot. And that could have potentially been the cause of the difficulty with unzipping. Or calculating the checks on over the TGZ. If it wasn't completely unzipped from squash FS and it's going to have to wait and it's going to have to go through that whole cycle of give me this chunk and now wait until it gets unzipped and then squash probably has to go out of its way so anyway, I think that he on the head I think he's on top of that. I don't know for sure, but I don't know if there's anything you can do about it. I suspect that was a problem of downloading precise was simply they don't wait for the network to come up and be verified it's up to spawn us. I believe that to be true. So if we get spawned and we and to expect to have a network. That's fine. Yeah, in other words, I think they're running my craft before the network connection has been established. And that's why you were seeing a lot of those kind of DNS and and fetch errors in the log files. If the network settled out, then it would recover but that you know goes through many retries anyway, there's something we should be able to like back up before we're going to never connection. Like, yeah, well, except that that's where the precise arrows being thrown from because it's going to the back end and trying to download precise, and it can't get it because it doesn't have a network connection so it keeps retrying and that consumes a lot of bandwidth and it slows everything down as a sometimes a cascading effect. But anyway, all I would say is leave precise alone for now we can we can get to it later. But it would be one less moving part that we have to deal with in this, bringing up of the panic core image. Okay, sorry to interrupt Ken. But the, I think the reason that's precise download issue came up is because we were investigating why the mic didn't work. And so is this not related to the mic not working. I mean it's related to the mic not working in that if precise doesn't get installed properly then you shouldn't expect anything to be recognized. Right. Okay, so you have a different solution for this that will be what I'm saying is that's not that's not the problem we have so so I also tried to build a tensor flow and basil. And because I got bored on Saturday and that reminded me of what a mess we're in with precise, and why precise is deployed the way it is, because it doesn't run on many versions of Python with that version of tensor flow. So everything's bundled pretty much as a binary together. Again, we can get to that, but I don't think that's imperative right now. What I did do is I created a script. Because the reason I wasted my time over the weekend trying to rebuild precise was I thought maybe we had a bad precise build for arch 64. And I don't even know how the hell we got a precise build for arch 64 is the first arch 64 operating system we've ever tried to run out right qt of this so I don't know how that happened but it did. Well, let me make sure that's not it. I was going to recompile it. Then I realized that building tensor flow on an eight gig pi four would take seven days and building the build tool basil will take 33 hours. So it has to be, you know, cross compile tool chain up in the cloud. And then I said, Well, let me see if it is precise. I wrote a script that doesn't use precise just to latch on to the microphone and record, and it throws the same error. So that demonstrated to me that it's not precise specific so then I could stop wasting time on that. But I download downloaded port audio which is where the exceptions being thrown and built it from source and put some debugging in there and figured out that at the end of the day. Because is a broken pipe being reported, which is a bit of a misnomer, because the broken pipe being reported on an input channel really means that you're getting overrun errors, and that you can't keep up with the mic input rate. And that's fine. And that's where I'm at, trying to figure out if that is endemic in their build, because we're containerized welcome to the wonderful world of containers, or if it's perhaps because it's misconfigured as Chris mentioned earlier, we're looking and seeing that all the config files seem to be the same. But I will say this, our mic comes in at 48k. And it comes in as a 32 bit entity, which is a bit uncommon, it's a high end audio device. In fact, I only think 32 bits are ultimately used anyway, but the point is that has to all be 16. I think it has to be configured properly as well and that could be the reason we're getting the overrun errors. But again, why we're not getting on the other machine is beyond me. What I told Ricardo before I went on vacation was I suspect it's performance related. And after my digging today, I'm even more suspicious that it's performance related. So that's that, that's where I'm at. And I'm in the middle of the Port Audio code and I'm trying to see if I can catch it and make it right without basically just missing frames all over the place and ruining the quality of the signal. And then I'm going to start one by one going over the two builds and seeing if there's anything from a surface level like configuration stuff for versioning or anything that's different. But yeah, so that's what I'm doing. Okay, well, this this is a, you know, we're not dealing with a real time operating system. So this is the kind of stuff that, you know, should give us nightmares. The. All right. So do you have a version that you can pass to Ricardo that doesn't include precise that's just like basically a pass through microphone sort of. I can give it to him. It's a five one piece of code script. But I'm pretty sure he knows it's not precise because I posted it in the thing today. You guys can keep up in the, you know, The other thing is fixed enough for now, like, because because there's now being distributed, like packaged up in the way that Microsoft expects with the tar balls and everything. We shouldn't hit that problem anymore. Yeah, as guest mentioned, and I failed to mention the other problem with that was they were whacking the tar ball after they unzipped it and precise then says, what's the check some on the tar ball it's not here I better go get it. So they fix that. Well, that bill doesn't hit the streets yet, but. Okay, so, so we're just down in this port audio module and down at the point where we're getting Mike input, I guess we used to calm under run errors, but the call over and errors I guess technically, but we can't keep up with the mics feeding us data packets at 48 K 32 bits. Okay, so that sounds like the. So if it's an under run what you're saying is that the port audio is not able to fill the buffer with data from the XMOS fast enough. No, it isn't overrun then yeah technically correct. No, it's the exact opposite it's filling it fine. The driver can't keep up with live Alice's stopping the buffer. Okay, so yeah so the data coming in from the XMOS chip is overrunning the buffer and we're not assuming it fast enough. Yeah, I remember I mean when you think about it that kind of makes sense, certainly from a misconfiguration potential, but even potentially from performance, your standard stuff is going to be 16 kilohertz, 8 bit maybe 16 bit right and more 48 kilohertz 32 bit. You know, so I mean I've seen, I think the first version came in at 8 bit so anyway yeah I don't know. I just don't know enough yet and maybe I could fix it maybe I can get in there and fix it so you know. It sounds like the kind of thing that might be I don't think this should be a it shouldn't be a performance issue if it's a performance issue it's like a really high level, or really low level I guess I'm thinking. You know between low level. Yeah, it's the hardware is filling the buffer, right and the first level driver can't pull it out fast enough. That's a that's to be a panic or issue like if they're on top of this if they're aware of this and they should be able to figure that out I think it's got to have something to do with priorities of the, you know, the. I agree and I agree it's a panic or issue but I was asked last week to do everything we can. I'm not saying you're doing anything wrong. I'm just saying that I think they may have more insight into the level. You know, setting up. I hope so. All right. So they're up to speed on where you've gotten with all of this. They are. Okay, cool. We've been back and forth quite a bit so. Little little little stuff you can talk about it's all in there. Sounds super fun. All right. Well, I guess I didn't mention on the record here that we're going to be shipping out some more sj 201s. And we'll send those out. We're going to get a new one of those so they'll have a fully working system when they get that we're going to ship those out today. And everyone who doesn't have a fully working sj 201 will get one as well. Is there any erratic data on the Rev five boards because, you know, like there's the itc detect issue I just want to make sure that Kevin didn't overlook something. Any particular other issues that you're concerned about or like the thing that comes to mind is that I to see detect will erase the lets. Oh, okay. Well, that's I don't I haven't heard of that issue before. He knows about we discussed it. Oh, okay. It was one of the first ones I reported I'm just wondering if there's a process so that he doesn't forget because it was early on in the process and it sounds like he's been off on other stuff. I'll I'll mention it with him. Okay. Talk to him later. Okay. Anything else that people want to bring up at this point. Okay. Well, it sounds like we're working full steam ahead at getting the hardware is underway and we're working towards getting this the Pantacore software distribution system up and running. And so we'll just keep working on it until we get it done. Because we got a lot of a lot of fun stuff to get to in terms of improving the user experience once we get a user experience online. So, we'll get there. All right. Well, thanks everybody. We'll just call it here for today. And before we break, are we expecting to meet with Pantacore at any point in the near future and. Once we get this once we get this build out we should do another demo. We're going to be working with them. They're obviously cautious. They want to make they want to have everything working 100%. Which is what we want as well. But, you know, obviously demos are a good way of seeing how close we are to that and putting some. Yeah, identifying where we're not and and putting the pressure on there so. We don't need to just make them have a demo, but I mean, we don't we don't need that. In person or anything like. Well, you know, as person as we get as in person as we get, we can do that by video. And then. This is on them right now. Is that correct that we're assuming that this is in their ball court or. Is there any possibility for cross communication and they think they're waiting on us. For any issue. For any issue. Yeah, as in they know that we're still waiting on a completely working system. Yes. So they're trying to begin to the. I mean, you're in the you're in the chat channel as well. I just wanted to make sure because that that's what I took away from there. I just wanted to hear you confirm that. Yeah. That they need to get this image working right with this. But yes, I agree. We should be we should be catching up shortly. So. I think. And once we test out these, these latest changes, and we, Derek, we need to get the Wi-Fi that onboarding and Wi-Fi stuff really. Ticked off and sent over so they can get on to that as well. Ideally. Yeah, it's still a good price. Yeah, if I can get past this shipment stuff and yeah, then I can get back on that. And ordering, we've got these two things left to order in this shipment dealt with and then I should be freed up to do that. Do you know when the next panic war builds coming out with the pulse audio patch thing? Sorry, I dropped out if that was a question for me. Do you know when the next panic war bills coming out with the pulse audio fix? If it's not, if it's not already built, then I will trigger a build now. Okay. If it's when it's ready, if it's already ready. Yeah, I'll be going to check after this. Okay, well on the demo front, I like the process that Josh instituted over a year ago in terms of doing continuous weekly demos just to let the team know where we are. So I'd like to start doing that now. I don't want to interfere with work, but I don't think that we're not at a stage where, you know, I think doing a demo is going to be preventing us from doing any useful work. So let's go ahead and set that up for Friday at the latest. If there's something available sooner, let's do, you know, we can set it up sooner, but for sure by Friday. And the need to be like publicly visible videos, right? We can just do the whole thing on a phone camera, right? Yeah. Yeah. The second you can do them all in a phone camera and either Derek or I can get our hands on a working S J 201. I want to do a super professionally lit very well. It does not like scripted but like, you know, put together like end to end demo because that that opens up a ton of doors for us in terms of like keeping the business team busy and starting to push through. You know, the, the business problems that we're, we're trying to solve, which have in many, many cases been on hold pending getting the technology to the point where we could do it. Right. So guess, can you set up that demo with Pantacore for Friday. Or you want to do it. So I mean, I thought we don't need to do with the core if their stuff is mostly out of the way. Yeah, I thought, I thought it feels like a some in somewhat a waste of time to spend like 10, 15 minutes with like eight people on a call. Why we do a thing. So I wonder if we just do that by video and and set up a meeting to actually talk about the outcome of that. And where we're going next and all that sort of stuff. Is that Well, I'll let Josh weigh in on that because this was his innovation. The first time around. What was that? It feels like a bit of a waste of time to have 15 people, eight people on a call for 10 to 15 minutes while we play around with the device. So my intuition would be to record the demo beforehand, send it out to everyone's everyone can consume it and then have the many to talk about, you know, where we're at and what what needs to come next. That's kind of not the point of the process initially, the point of the process initially is, is to partially motivate but then also partially highlight with the team where the problems are the the issue with doing the demos in a scripted or pre recorded way is that people get really used to using the interface and they don't go off script right there isn't the ability to inject additional questions or to kind of go off off the beaten path. And as a result you end up with a really successful video for a product that when you open it is really terrible. And so, you know, for the first few I'd like to have our team all on board and so that we can ask questions and go back and forth. But once they read once it reaches the point where the things useful and I can set it up in my kitchen. It ceases to be a real issue because you know we're all using it day to day, but right now, you know, none of us at least I'm not using it every day. So, yeah, I'd like to have everybody on the call at least for the first few. Okay. Yeah. One of the things that we did have in place before as well was the ability for all the developers myself and Josh to install the build on a device that was all the same. You know, sounds like we might get very close to that this week with Kevin sitting out some boards. So, that would be a good thing to do the day before the demo is to say here's the latest build fired up. You know, even if it's not a priority, if you, you know, it's not your main priority, go ahead and install it. We should all be running the latest version of the software. And that's one of the points of this panticore system, right. Which makes sure we're all on the right branch. Yeah. So there's, there's two sides to it. Like, if, if people are just like wanting the latest software, then, then we can, we can push that out to everyone automatically. But, you know, at this stage, we do want to be going through that, you know, raw, out of, you know, unboxing kind of experience over and over and over again, as much as possible. So. Right. Okay. Okay. Well, yeah, guys, if you could organize that for Friday, that'd be great. And all right. So anything else? All right. Then we'll call it there for real this time and talk to you all tomorrow.