**** BEGIN LOGGING AT Sat Apr 10 02:59:58 2021
Apr 10 03:19:53 <DhruvaGole[m]> <jkridner[m]1 "The mounting to that frame is co"> ahh this lacks mechanical support for the beagle bone, which means I probably will need to makeshift some solution by tying up the BBAI+RoboCape to the frame of something, and then manually attach wires to all the pins of the Balboa board correct?
Apr 10 03:30:45 <DhruvaGole[m]> jkridner: You want me to completely bypass the Balboa controllerboard and use the RoboCape+BBAI instead right?
Apr 10 03:31:24 <DhruvaGole[m]> > <@jkridner:beagleboard.org> The mounting to that frame is complex.
Apr 10 03:31:25 <DhruvaGole[m]>  * ahh this lacks mechanical support for the beagle bone, which means I probably will need to makeshift some solution by tying up the BBAI+RoboCape to the frame of something, and then manually attach wires from our Cape to the motors of the kit correct?
Apr 10 03:31:38 <DhruvaGole[m]>  * ahh this lacks mechanical support for the beagle bone, which means I probably will need to makeshift some solution by tying up the BBAI+RoboCape to the frame or something, and then manually attach wires from our Cape to the motors of the kit correct?
Apr 10 03:40:41 <DhruvaGole[m]> jkridner:  I'd rather use this: https://www.renaissancerobotics.com/eduMIP.html as it's already Robo Cape compatible...
Apr 10 03:40:41 <DhruvaGole[m]> Is there a specific reason why you asked me to use the pololu one?
Apr 10 03:42:01 <DhruvaGole[m]> umm is it cuz it's out of stock and you don't think it can come in stock anytime soon?
Apr 10 04:16:57 <jkridner[m]> i don’t think he’s making more. I have some though. maybe i could ship.
Apr 10 04:19:14 <DhruvaGole[m]> okay sure, as that could end up saving a lot of time jkridner
Apr 10 04:19:37 <DhruvaGole[m]> jkridner: Does the rest of the proposal seem okay to you? (https://elinux.org/BeagleBoard/GSoC/2021_Proposal/DhruvaGole#Details_of_implementation)
Apr 10 04:19:52 <DhruvaGole[m]> I have also modified the timeline according to your latest suggestions
Apr 10 04:20:15 <DhruvaGole[m]> where I have alotted more time to the balancing part and lesser to the I2C, API, UArt...
Apr 10 04:23:06 <DhruvaGole[m]> Also removed grove modules thay were unnecessary
Apr 10 05:51:24 <YadnikBendale[m]> <jkridner "I think you'd overwritten the te"> Thank youjkridner. The same thing happened yesterday but i did undo the changes.
Apr 10 07:58:19 <DhruvaGole[m]>  * jkridner: Does the rest of the proposal seem okay to you? (https://elinux.org/BeagleBoard/GSoC/2021_Proposal/DhruvaGole)
Apr 10 09:57:43 <jduchniewicz> ds2:  I read your mail and updated the proposal accordingly. I am not sure If I understood the requests for code changes there properly, but I included sample data reading out of the computed texture
Apr 10 09:59:17 <jduchniewicz> ds2:  Also for the other algorithms, some shader code will be required to do the computations (convolutions and other examples, like matrix multiplications). I think that I should ask more experienced graphics people / google for it, what other common operations would be best accelerated in the shader code
Apr 10 10:24:00 <jduchniewicz> giuliomoro[m]:  as for the ALSA driver, could you specify once more what exactly is desired? We need a unified interface for doing playback and recording via ALSA api, but still have the audio running not through the kernel but through a RT thread
Apr 10 10:24:11 <jduchniewicz> giuliomoro: this one :)
Apr 10 10:30:01 <jduchniewicz> giuliomoro: From what I see ALSA requires having a pointer into the data stream. How I solved it in the past, was to have a timer started when a capture was commenced and on the timer elapsed I asked the device to feed me more data, doing the push-pull.
Apr 10 10:31:02 <jduchniewicz> probably with the BELA running its own threads the only thing I find complicated is tying the data output/input to ALSAs one
Apr 10 10:32:38 <jduchniewicz> so I think that having a device running through the ALSA subsystem requires at least informing ALSA where in the circular buffer of data we are
Apr 10 10:33:02 <jduchniewicz> however I am not sure if by doing so we are not throwing out all the gains from the independent audio processing in RT
Apr 10 10:34:03 <jduchniewicz> because application tied to the ALSA api will be still subject to ALSA api calls and these are done with the kernel latency
Apr 10 10:34:22 <jduchniewicz> at least that is what I understand from my limited experience
Apr 10 10:34:29 <jduchniewicz> maybe not that limited :D
Apr 10 10:43:47 <jduchniewicz> https://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html here you have some info about how the ALSA api is used
Apr 10 10:46:53 <jduchniewicz> it may be possible, but I still do not know how the data is delivered to user in RT via BELA
Apr 10 10:48:26 <jduchniewicz> if the user is tied to ALSA API they will be using normal Linux threads right?
Apr 10 10:48:52 <jduchniewicz> or you want to transcend over them and use the RT xenomai threads even though using the ALSA api
Apr 10 10:49:14 <jduchniewicz> don't know if this is understandable
Apr 10 10:49:36 <jduchniewicz> but some clarifications are needed :)
Apr 10 11:38:10 <DhruvaGole[m]> <jduchniewicz "don't know if this is understand"> +1 , didn't understand either.
Apr 10 11:42:45 <jduchniewicz> actually understanding ALSA details is quite complex and took me a lot of time to get a grasp of what is happening underneath
Apr 10 13:48:48 * OmkarBhilare[m]  < https://matrix.org/_matrix/media/r0/download/matrix.org/wlAQoxvBPWrXeLFDdBFUPidz/message.txt >
Apr 10 13:51:43 <satacker[m]> <jkridner[m]1 "satacker: I recommend you look t"> jkridner: I am confused a bit. Do I need to mention the file permissions and all the other verification cases in the proposal ? Also it would become a bit of hard coding that's the reason I had mentioned to traverse the  device tree so that its reflected directly everytime user configures it.
Apr 10 14:18:09 <Abhishek[m]_> satacker: Your proposal should be a high level document. Keep implementation details separate.
Apr 10 14:19:03 <Abhishek[m]_> How do you traverse device tree?
Apr 10 14:19:48 <Abhishek[m]_> jduchniewicz: Which proposal are you submitting?
Apr 10 14:19:51 <satacker[m]> i traverse the inodes of devicetree that gets mounted
Apr 10 14:20:15 <jduchniewicz> GPGPU with GLES
Apr 10 14:20:31 <Abhishek[m]_> I saw a bit of ALSA stuff from you also- you taking it up?
Apr 10 14:21:09 <satacker[m]> <Abhishek[m]_ "I saw a bit of ALSA stuff from y"> did "you" meant jduchniewicz ?
Apr 10 14:21:36 <Abhishek[m]_> Yes
Apr 10 14:21:56 <jduchniewicz> ALSA stuff is in the phase of thinking through
Apr 10 14:22:03 <jduchniewicz> not sure if it is possible to do
Apr 10 14:22:20 <jduchniewicz> at least not with what giuliomoro achieved (RT capabilities)
Apr 10 14:22:28 <jduchniewicz> maybe
Apr 10 14:22:32 <jduchniewicz> very maybe
Apr 10 14:25:22 <Abhishek[m]_> giuliomoro: Sorry if you already explained this somewhere before and I can’t scroll to it - is there a link to what you plan to achieve?
Apr 10 14:25:42 <Abhishek[m]_> I mean the BELA proposal
Apr 10 14:34:28 <Abhishek[m]_> Hmm, reading through some more context
Apr 10 14:34:58 <Abhishek[m]_> So what I understand - provide an interface through ALSA
Apr 10 14:35:41 <Abhishek[m]_> Right now, it’s Xenomai and bypasses Linux abstractions entirely
Apr 10 14:36:12 <Abhishek[m]_> (Note: I’m a mentor just trying to understand the idea)
Apr 10 14:37:02 <Abhishek[m]_> I know of PulseAudio and JACK as userspace abstractions - can or does Bela use them now?
Apr 10 14:42:00 <Abhishek[m]_> satacker: saw an idea of jkridner’s to build a web interface around beagle config. I think that’s great. How would you want to prioritize it?
Apr 10 14:42:58 <jduchniewicz> from what I understand, having BELA stuff exposed as ALSA cards/devices would be useful for using it in unified way
Apr 10 14:43:08 <jduchniewicz> not every system has pulseaudio or JACK
Apr 10 14:43:09 <giuliomoro[m]> <jduchniewicz "because application tied to the "> Right.  So, I guess what would be needed then is a rtdm (Xenomai) ALSA driver, where calls to, e.g.: `snd_pcm_readn()` block on a rt-safe `ioctl()` or read()`. However, this would not by itself be enough, as the calling thread should be a Xenomai thread to begin with. In principle this could be implemented in user space  in `libasound` (e.g.: if the thread that calls
Apr 10 14:43:09 <giuliomoro[m]> into snc_pcm_readn() is not Xenomai, make it a Xenomai thread).
Apr 10 14:44:04 * giuliomoro[m]  < https://matrix.org/_matrix/media/r0/download/matrix.org/XgJXfbcsRqyhMhVjmRiOKtRf/message.txt >
Apr 10 14:44:45 <Abhishek[m]_> Hmm, I see
Apr 10 14:51:40 <jduchniewicz> probably patching libasound would be sound (no pun intended)
Apr 10 14:53:09 <jduchniewicz> maybe it could also be done with only a kernel driver and ensuring the data is read on a Xenomai thread
Apr 10 14:53:20 <satacker[m]> Abhishek: If you mean setting up a web server for it. I can do it . But now i seriously feel short of time. That's a cool idea by jkridner
Apr 10 14:53:26 <jduchniewicz> however the libasound alternative seems to be more resilient
Apr 10 14:54:08 <jduchniewicz> would such patching be mainlinable? most probably not
Apr 10 14:54:15 <Abhishek[m]_> satacker: yep, good that you have ideas. Post everything or keep record of it
Apr 10 14:55:47 <satacker[m]> Adding it in future scope for now
Apr 10 14:56:10 <Abhishek[m]_> satacker: Prioritize what is implementable in GSoC timeframe and stack rank
Apr 10 14:57:19 <jduchniewicz> probably for now the libasound is much better than a kernel driver. However, having custom libasound will be cumbersome, won't it be?
Apr 10 14:57:45 <jduchniewicz> wishes there was somebody who knew ALSA better
Apr 10 14:58:39 <satacker[m]> Abhishek: I think the current state is not too less and not too big. A bit nervous about adding more things and not committing to those.
Apr 10 15:00:26 <giuliomoro[m]> <jduchniewicz "would such patching be mainlinab">
Apr 10 15:01:48 <jduchniewicz> I did have to create some virtual ALSA devices one time
Apr 10 15:02:21 <jduchniewicz> however I tied them to the real ones
Apr 10 15:03:54 <giuliomoro[m]> <jduchniewicz "it may be possible, but I still "> The Bela user audio callback is passed a pointer to a location in memory where the data is (https://github.com/BelaPlatform/Bela/blob/master/core/PRU.cpp#L1222) . An example of such audio callback (`render()`) is [here](https://github.com/BelaPlatform/Bela/blob/master/examples/Fundamentals/passthrough/render.cpp). All the relevant stuff is in `BelaContext`:
Apr 10 15:03:54 <giuliomoro[m]> https://github.com/BelaPlatform/Bela/blob/master/include/Bela.h#L376
Apr 10 15:04:47 <giuliomoro[m]> > <@jduchniewicz:matrix.org> it may be possible, but I still do not know how the data is delivered to user in RT via BELA
Apr 10 15:04:47 <giuliomoro[m]>  * The Bela user audio callback is passed a pointer to a location in memory where the data is (https://github.com/BelaPlatform/Bela/blob/master/core/PRU.cpp#L1222) . An example of such audio callback (`render()`) is [here](https://github.com/BelaPlatform/Bela/blob/master/examples/Fundamentals/passthrough/render.cpp). All the relevant pointers are in `BelaContext`:
Apr 10 15:04:47 <giuliomoro[m]> https://github.com/BelaPlatform/Bela/blob/master/include/Bela.h#L376e
Apr 10 15:06:19 <jduchniewicz> maybe there is a need for a tandem of driver and alsalib hacking for this
Apr 10 15:06:44 <jduchniewicz> because I don't see an easy way of creating a virtual device without a real one
Apr 10 15:08:21 <jduchniewicz> it seems like a good project but with a scope bigger than this year's gsoc
Apr 10 15:08:40 <jduchniewicz> at least I am sure it is not realisable in the timeframe
Apr 10 15:08:53 <jduchniewicz> knowing how much time I spent on ALSA adventures
Apr 10 15:08:58 <jduchniewicz> and debugging this
Apr 10 15:09:16 <jduchniewicz> good to have some ideas on how to approach this though
Apr 10 15:09:59 <jduchniewicz> maybe it would be realisable if I was sure of how to do it
Apr 10 15:10:18 <jduchniewicz> nevertheless I am open to further discussing it :)
Apr 10 15:10:49 <jduchniewicz> let me know what is your opinion on that
Apr 10 15:31:59 <giuliomoro[m]> My guess is that the driver may not be necessary in that also `aplay -l` or whatever the device listing function call is in C would go through `libasound` ... but I am not sure if we are leaving something out.
Apr 10 15:31:59 <giuliomoro[m]> Now, if this was simply a patching of `libasound`, I think it should be adequate for the timeframe available.
Apr 10 15:31:59 <giuliomoro[m]> One could even add a virtual MIDI device for delivering GPIO I/O and sensor/actuator analog I/O at non-audio rate.
Apr 10 15:40:57 <satacker[m]> <satacker[m] "Abhishek: I think the current st"> *ahem , i wonder if i can get quotes to submit it 😀
Apr 10 16:22:20 <ArchismanDey[m]> Abhishek: Have a look at my proposal if you are free :)
Apr 10 16:25:09 <ArchismanDey[m]> pratimu: Made some of the changes you requested and added you as another mentor, check out my proposal if you are free!
Apr 10 16:35:48 <jduchniewicz> @giuliomoro I will look into it more and maybe it will become more clear
Apr 10 16:36:02 <jduchniewicz> Maybe it is indeed possible to do only from the userspace
Apr 10 16:52:20 <Willmish> Hi everyone! Im new here. I am a current first year student with some experience with Python, C  and Electronics and I am considering making a proposal for the MicroPython for BeagleConnect Freedom project.
Apr 10 16:52:33 <Willmish> Sorry for joining so late :/
Apr 10 16:58:03 <Willmish> I was wondering if someone already has a proposal for that project or is interested in it? Or who can I ask to get more information about it.
Apr 10 17:00:40 <OmkarBhilare[m]> https://elinux.org/Category:GSoCProposal2021
Apr 10 17:01:01 <OmkarBhilare[m]> These are the all proposals
Apr 10 17:12:09 <jduchniewicz> jkridner: should have more knowledge about it. I was researching about it but I am already researching two other proposals
Apr 10 17:13:39 <jduchniewicz> There was some talk about it earlier, about including circuitpython as well as micropython. And I believe the relevant parts should be implemented in C and exposed as Python classes
Apr 10 17:13:50 <jkridner[m]> scrolling back in history or reading the logs can be very valuable.
Apr 10 17:14:16 <jkridner[m]> chatting a lot can help build a relationship with other community members.
Apr 10 17:16:23 <jduchniewicz> Be sure to read up the resources attached to the idea on the ideas page
Apr 10 17:38:05 <DhruvaGole[m]> jkridner: please can you check github, I have asked a few questions on some PRs and issues
Apr 10 19:09:58 <StevenSchrstedt[> ds2: have you seen my proposal and sample code for the gpgpu project? I havent heard back from you. (here are the links: https://elinux.org/BeagleBoard/GSoC/2021ProposalGPGPU, https://github.com/StevenSchuerstedt/GPGPU_with_OpenGL) Also I will include more details soon. I thought about adding one more sample besides matrix multiplication/convolution, but Im not sure what people use the beagleboard for and what
Apr 10 19:09:58 <StevenSchrstedt[> computation needs to be accelerated
Apr 10 19:13:07 <satacker[m]> lorforlinux Abhishek should I submit. (Sorry for Saturday night interruption)
Apr 10 19:13:18 <satacker[m]> * lorforlinux Abhishek should I submit? (Sorry for Saturday night interruption)
Apr 10 20:20:22 <ds2> jduchniewicz: quick read - seems okay. I suggest you get an updated snapshot of it into the Google site if you haven't done that yet.... also get another mentor to look through it just to have another set of opinions
Apr 10 20:38:35 <Willmish> Quick question, If Im considering doing a project, should i contact the project's mentor directly?
Apr 10 20:39:02 <satacker[m]> Right here is fine
Apr 10 20:42:18 <Willmish> cool cool
Apr 10 20:44:36 <pratimu[m]> Archisman Dey: Was completing assigments, any other changes from the last version?
Apr 10 20:45:23 <pratimu[m]> Willmish: The mentors are active on this channel, you can tag them using their username on the ideas list
Apr 10 20:45:30 <ArchismanDey[m]> <pratimu[m] "Archisman Dey: Was completing as"> Added some details for the break/continue and return related grammar changes, and added you as a possible mentor
Apr 10 20:45:56 <Willmish> jkridner So Im curious about the project regarding MicroPython implementation for BeagleConnect Freedom. I have some prior experience with C (mostly from university-related work) and Arduino/Rpi (individual projects), and quite a bit of experience in Python.
Apr 10 20:46:08 <Willmish> pratimu[m] thanks!
Apr 10 20:46:36 <pratimu[m]> Archisman Dey: Okay
Apr 10 20:46:41 <ArchismanDey[m]> <Willmish "jkridner So Im curious about the"> To tag someone, write @ followed by their name, just writing their name won't tag them
Apr 10 20:47:04 <pratimu[m]> Make sure to get Abhishek's comments as well
Apr 10 20:47:21 <pratimu[m]> Archisman Dey:
Apr 10 20:47:41 <ArchismanDey[m]> Also added relational and bitwise operators and ability to initialize integers from hex, like int a:= 0xF528A
Apr 10 20:47:54 <ArchismanDey[m]> <ArchismanDey[m] "Also added relational and bitwis"> as suggested by vedant16
Apr 10 20:48:34 <YadnikBendale[m]> jkridner: I  have completed the proposal for the MicroPython implementation for BeagleConnect Freedom project.It would be truly grateful if you could have a look at it and give your inputs.https://elinux.org/BeagleBoard/GSoC_2021/Micropython_for_BeagleConnect_Freedom
Apr 10 20:48:44 <YadnikBendale[m]>  * jkridner: I  have completed the proposal for the MicroPython implementation for BeagleConnect Freedom project. It would be truly grateful if you could have a look at it and give your inputs.https://elinux.org/BeagleBoard/GSoC_2021/Micropython_for_BeagleConnect_Freedom
Apr 10 20:48:45 <ArchismanDey[m]> <pratimu[m] "Make sure to get Abhishek's comm"> He hasn't been replying lately, maybe he is busy right now
Apr 10 20:48:46 <pratimu[m]> Archisman Dey: Alright👍️
Apr 10 20:49:55 <pratimu[m]> Archisman Dey: Yes he should reply soon, I'll remind him once
Apr 10 20:50:14 <ArchismanDey[m]> pratimu: thanks!
Apr 10 20:51:09 <YadnikBendale[m]> jkridner:Writing driver for UART was not mentioned on the ideas page.However I have added it in my proposal since it I thought UART would be a very important considering that that the BeagleConnect Freedeom is built for IOT and IIOT applications.
Apr 10 20:51:51 <YadnikBendale[m]> jkridner: My timeline is a bit generic,once I get your input I will write it in a more micro manner.
Apr 10 20:54:46 <YadnikBendale[m]> Meanwhile it would be very helpful if any mentor online can have a look at my proposal once..https://elinux.org/BeagleBoard/GSoC_2021/Micropython_for_BeagleConnect_Freedom
Apr 10 21:02:15 <YadnikBendale[m]>  * jkridner:Writing driver for UART was not mentioned on the ideas page.However I have added it in my proposal since it I thought UART would be very important considering that that the BeagleConnect Freedeom is built for IOT and IIOT applications.
Apr 10 21:49:05 <Willmish[m]> @jkridner So Im curious about the project regarding MicroPython implementation for BeagleConnect Freedom. I have some prior experience with C (mostly from university-related work) and Arduino/Rpi (individual projects), and quite a bit of experience in Python.
**** ENDING LOGGING AT Sun Apr 11 02:59:56 2021