| *** tpb has joined #timvideos | 00:00 | |
| *** cr1901 has joined #timvideos | 00:09 | |
| *** miselin has joined #timvideos | 01:02 | |
| *** sb0 has joined #timvideos | 01:25 | |
| mithro | cr1901_modern: Do you have an example of this being connected up? | 02:48 |
|---|---|---|
| cr1901 | mithro: Check the master branch of my copy of the repo. It has an extra commit showing how to connect it to minispartan6_base and video | 02:50 |
| mithro | cr1901: Link? | 02:50 |
| mithro | https://github.com/cr1901/HDMI2USB-misoc-firmware/blob/master/targets/minispartan6_video.py#L53 ? | 02:51 |
| tpb | Title: HDMI2USB-misoc-firmware/minispartan6_video.py at master · cr1901/HDMI2USB-misoc-firmware · GitHub (at github.com) | 02:51 |
| cr1901 | mithro: Yes, that | 02:52 |
| cr1901 | Netbook is currently having a stroke, sorry | 02:52 |
| mithro | cr1901: I don't quite understand the arguments... | 02:52 |
| mithro | Be back in 30 minutes | 02:52 |
| cr1901 | mithro: Hopefully by that time my netbook will have decided to STOP USING SWAP | 02:54 |
| cr1901 | mithro: First input argument is the clock frequency of the counter. The second input argument is the max bit width of pulse counter attached to the signal of interest, that resets to zero every clock cycle. The third input argument is the accumulator width, which is incremented by the number of pulses counted every clock cycle until 1 second has elapsed. | 03:01 |
| cr1901 | So a 6-bit pulse counter would let you count a signal that's up to 64 times higher frequency that the clock frequency of the counter (within reason; you'll hit the bandwidth of the IO pin before that) | 03:02 |
| cr1901 | mithro: My energy has left me. I need to sleep, sorry :(... | 03:10 |
| *** Bertl_oO is now known as Bertl_zZ | 03:37 | |
| *** sb0 has quit IRC | 04:25 | |
| mithro | cr1901: Have a good sleep | 04:39 |
| *** rohitksingh_work has joined #timvideos | 04:39 | |
| *** rohitksingh_work has quit IRC | 04:41 | |
| *** rohitksingh_work has joined #timvideos | 04:43 | |
| mithro | conda has been really unreliable lately :( | 05:28 |
| mithro | hey rohitksingh_work | 05:28 |
| rohitksingh_work | mithro: hi! | 05:28 |
| *** CarlFK has quit IRC | 05:33 | |
| *** CarlFK has joined #timvideos | 05:33 | |
| *** ChanServ sets mode: +v CarlFK | 05:33 | |
| *** ssk1328 has joined #timvideos | 05:39 | |
| *** sb0 has joined #timvideos | 05:41 | |
| ssk1328 | mithro: Looking at the block diagrams I had some questions | 05:42 |
| mithro | ssk1328: shoot! | 05:43 |
| ssk1328 | mithro: Earlier the pixel stream first goes through VTG, (which does timing hsync vsync stuff), and then through the Driver(which does the all the mixing) | 05:43 |
| mithro | ssk1328: BTW your photo link is broken on your snippets https://photos.google.com/photo/AF1QipMZeS7uMiMvNvzdPWOcvkVo0GXIdrfmDg-019iE is a 404 | 05:43 |
| tpb | Title: Sign in - Google Accounts (at photos.google.com) | 05:43 |
| mithro | ssk1328: Earlier? You mean currently, or? | 05:46 |
| ssk1328 | mithro: But now you propose that the mixing be done before timing, correct? And the timing generator is connected to Output blocks | 05:46 |
| ssk1328 | mithro: Earlier means the connections before any reworking | 05:46 |
| mithro | ssk1328: Well, it is unclear to me if the timing generator would need to be connected to the mixing bit | 05:47 |
| mithro | ssk1328: What I'm actually saying is that we move the mixing out into its own module | 05:48 |
| ssk1328 | mithro: So I think that the new Mixer block will have existing VTG module followed by Driver module | 05:48 |
| ssk1328 | mithro: The mixing float modules will be used in the Driver module as before | 05:49 |
| mithro | ssk1328: The Mixing module shouldn't really be inside the driver module | 05:51 |
| mithro | ssk1328: Really the mixing module is just an "adapter" it takes N pixels layout in and produces a single pixel output | 05:52 |
| ssk1328 | mithro: Yes | 05:52 |
| ssk1328 | mithro: So, the driver should remain as before | 05:53 |
| ssk1328 | mithro: One driver module per ouput | 05:53 |
| mithro | ssk1328: well, previously the driver contained the dma engine, right? | 05:53 |
| ssk1328 | mithro: dma was defined independently, outside driven, directly in the __init__.py file of hdmi_out folder | 05:54 |
| mithro | aah, yean I'm getting the "HDMIOut" and "Driver" modules confused | 05:54 |
| ssk1328 | mithro: HDMIOut is the big thing that contained everthing | 05:55 |
| mithro | gah, I understood this yesterday and now I've already forgotten everything | 05:56 |
| mithro | ssk1328: How does the VTG work? | 05:56 |
| mithro | self.timing = Sink(timing_layout) | 05:56 |
| mithro | self.pixels = Sink(pixel_layout(pack_factor)) | 05:56 |
| mithro | self.phy = Source(phy_layout(pack_factor)) | 05:56 |
| mithro | It has two sinks and a source | 05:57 |
| ssk1328 | mithro: VTG takes timing parameters from FrameInitiator and pixels from VTG | 05:57 |
| ssk1328 | mithro: And there is an FSM which controls when to send pixels as per the timing parameters received | 05:57 |
| ssk1328 | mithro: And I guess the Async FIFO at the start of Driver maintains the output correctly | 06:00 |
| mithro | So, looking at https://migen.readthedocs.io/en/latest/_images/fbflow.png | 06:00 |
| ssk1328 | mithro: Yes | 06:00 |
| mithro | ssk1328: So, looking at the diagram in your document I labelled "P1" - does that make sense? | 06:03 |
| ssk1328 | mithro: I just think that VTG should be before Mixer Block | 06:06 |
| mithro | ssk1328: Why? | 06:06 |
| ssk1328 | mithro: And Mixer output is directly connected to HDMI_OUT | 06:06 |
| ssk1328 | mithro: The existing mixing is done after VTG does its magic, so I am not sure this will work before VTG | 06:07 |
| mithro | ssk1328: Does the mixing use any of the VTG created signals? | 06:14 |
| ssk1328 | mithro: Just the pixel layout signals | 06:15 |
| mithro | ssk1328: Yeah - which I think means it should be before the VTG... | 06:17 |
| ssk1328 | mithro: Okay | 06:17 |
| ssk1328 | mithro: I am gonna test this without mixing first just in case | 06:18 |
| mithro | ssk1328: If it becomes an independent module, then it should be pretty easy to move it after the VTG if it ends up being needed, right? | 06:19 |
| ssk1328 | mithro: Yes | 06:19 |
| ssk1328 | mithro: That shouldn't be much of an hassle | 06:19 |
| mithro | ssk1328: You could replace the mixing block with something which just takes the [pixel, pixel, pixel](sink) layout into [pixel](source), [pixel](source), [pixel](source) output? | 06:20 |
| mithro | ssk1328: I think it might make sense to start a totally new branch and create the structure in Diagram P1/P2 with a dummy mixing block | 06:24 |
| mithro | ssk1328: We can then merge that bit and add the mixing block in a seperate pull request? | 06:25 |
| ssk1328 | mithro: Okay | 06:25 |
| mithro | ssk1328: Does that make sense to you? | 06:25 |
| ssk1328 | mithro: Yeah so first rework the HDMI_OUT as per the blopck diagram without any mixing just direct conections, and then once this is one add mixing to the mixer module | 06:26 |
| ssk1328 | *done | 06:26 |
| mithro | ssk1328: I mean, does it make sense to you for us to split the work into this structure? | 06:27 |
| ssk1328 | mithro: Yeah, so I have another technical doubt | 06:27 |
| ssk1328 | mithro: Earlier Till the driver module each layout has packfactor number of pixels per clock cycle | 06:28 |
| ssk1328 | mithro: And in the driver module (somewhere int he FIFO module) this is separated into individual pixels, after which mixing is done | 06:29 |
| ssk1328 | mithro: Plus we need to take care of fact that multiplier value will later depend upon (x,y) value in frame, which comes from timing stuff in VTG | 06:30 |
| ssk1328 | mithro: These are two separate concers actually | 06:31 |
| ssk1328 | *concerns | 06:31 |
| mithro | ssk1328: The pixel gather already knows the "address" of the pixel... | 06:32 |
| mithro | ssk1328: Lets give it a go and see? If it doesn't work we can change it | 06:34 |
| ssk1328 | mithro: Thats just the base address, the pixel gather, should have some counters and all to count this | 06:34 |
| ssk1328 | mithro: Okay | 06:34 |
| mithro | ssk1328: Diagram P4 would be how it connects up in your scenario, right? | 06:38 |
| ssk1328 | mithro: Yes | 06:38 |
| ssk1328 | mithro: It shouldn't be too difficult to rework it though | 06:39 |
| mithro | ssk1328: okay | 06:41 |
| mithro | cr1901: So I added the freq detector to the hdmi input and the numbers don't seem to make sense | 06:54 |
| mithro | cr1901: The computer says it is sending a pixel clock of 74.250MHz | 06:54 |
| mithro | cr1901: The counter is saying; -- freq: Frequency: 118 MHz (118801418 Hz) | 06:55 |
| mithro | cr1901: I wonder if I'm using the wrong values for the parameters | 06:55 |
| mithro | cr1901: It might be because I'm giving the wrong value for the first parameter, trying the same value as clk_freq now... | 07:14 |
| mithro | cr1901: It works! | 07:20 |
| mithro | cr1901: freq: Frequency: 74 MHz (74250845 Hz) | 07:20 |
| mithro | cr1901: https://github.com/timvideos/HDMI2USB-misoc-firmware/compare/master...mithro:hdmi-freq-counter | 08:00 |
| tpb | Title: Comparing timvideos:master...mithro:hdmi-freq-counter · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 08:00 |
| *** sb0 has quit IRC | 08:28 | |
| xfxf | thaytan: are you around? i have some gstreamer questions i'd love some help with | 08:30 |
| xfxf | in short, trying to sync hdmi2usb v4l video with USB audio + voctomix using a central network clock. the biggest sync issues appeared to be solved by using alsasrc provide-clock=false slave-method=resample, but we're still a few frames mismatched on the machine taking in the camera - i assume the camera delays the picture by a few frames doing internal | 08:31 |
| xfxf | processing | 08:31 |
| xfxf | curious how i introduce a delay into one part of a muxed pipeline | 08:31 |
| xfxf | (also, is using slave-method=resample advised, or use another?) | 08:32 |
| xfxf | thaytan: i ported over the set_offset() stuff into carl's script which is sort of working, see: | 09:21 |
| xfxf | https://github.com/xfxf/voctomix-outcasts/blob/master/ingest.py#L242 | 09:21 |
| tpb | Title: voctomix-outcasts/ingest.py at master · xfxf/voctomix-outcasts · GitHub (at github.com) | 09:21 |
| xfxf | is there a better way of doing this? i note if i make the delay too long (i.e. 1) then everything breaks. need to increase video/audio buffers or something? | 09:22 |
| xfxf | CarlFK: you may also be interested in above, appears to fix your 1 second audio delay issue | 09:22 |
| CarlFK | xfxf: what does it do when it doesn't need fixing? | 09:24 |
| xfxf | audio video totally out of sync | 09:30 |
| mithro | brb | 09:31 |
| mithro | well | 09:31 |
| mithro | be back after dinner | 09:31 |
| *** Bertl_zZ is now known as Bertl | 09:39 | |
| *** sb0 has joined #timvideos | 09:50 | |
| xfxf | CarlFK: i suspect you'd only see this if displaying hdmi2usb video with audio from your camera. for this conf i'm not using blackmagic cards, instead hdmi2usb+usb audio on mixer pc, hdmi2usb over network for presenter laptop capture | 09:57 |
| CarlFK | xfxf: I had audio into camera, camera into bm card, and 'sometimes' (like 5%?) I get the 1 second problem | 10:18 |
| xfxf | hmm, with my altered script above, i seem to now have perfectly synced video with --delay-video arguments on both computers | 10:19 |
| xfxf | will let it run for ages | 10:19 |
| xfxf | i'll correct an issue i found in the script and send you a PR | 10:19 |
| xfxf | assuming this is actually fixed, it may not be | 10:20 |
| xfxf | wait, nope, audio getting out of sync. sigh | 10:25 |
| *** danielki has joined #timvideos | 10:25 | |
| CarlFK | xfxf: I seem to remember somthing like "oh, alsa src isn't using the right clock..." | 10:29 |
| xfxf | yes, the patch above addresses that | 10:29 |
| CarlFK | what patch? | 10:30 |
| xfxf | the url i pasted above | 10:31 |
| xfxf | i forked your repo | 10:31 |
| xfxf | oh wait, audio didn't get out of sync. voctomix's gui just did, restarted it, back in sync | 10:32 |
| xfxf | that's annoying, i thought that was fixed | 10:32 |
| xfxf | do you still get that? | 10:32 |
| CarlFK | not sure. I haven't seen any sync issues from PyOhio. 4 machines, one of them only had 2 gig.. so things got ... icky, but stayed in sync | 10:48 |
| xfxf | and all of yoru audio was via blackmagic, or any via alsa or pulse? | 10:52 |
| CarlFK | bm | 10:57 |
| CarlFK | I haven't done any alsa/pulse | 10:57 |
| xfxf | right, that's what i thought, so i'm dealing with a new problemset | 10:58 |
| xfxf | yay | 10:58 |
| *** ssk1328 has quit IRC | 11:15 | |
| *** ssk1328 has joined #timvideos | 11:17 | |
| *** rohitksingh_work has quit IRC | 11:25 | |
| *** rohitksingh_work has joined #timvideos | 11:26 | |
| *** cr1901 has quit IRC | 11:55 | |
| mithro | CarlFK: https://github.com/timvideos/HDMI2USB-misoc-firmware/pull/283#issuecomment-238178718 | 11:58 |
| tpb | Title: Frequency Counter for Debugging by cr1901 · Pull Request #283 · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 11:58 |
| *** cr1901 has joined #timvideos | 12:09 | |
| thaytan | xfxf, In a python script you can adjust delays on a pad using gst_pad_set_offset() that will affect all data going through it | 12:28 |
| thaytan | by adjusting Segment events | 12:28 |
| thaytan | ah, that's the 2nd link | 12:30 |
| thaytan | slave-method=resample is OK if it's working | 12:30 |
| thaytan | I think we could improve it | 12:30 |
| thaytan | it's a bit too eager to switch resampling rate | 12:31 |
| thaytan | and the resampling is only linear interpolation - but that's almost certainly fine for speech | 12:31 |
| xfxf | is slave-method=re-timestamp any better? | 12:35 |
| xfxf | (i had some sync issues before, restarted using this) | 12:43 |
| mithro | ssk1328: How are thing going? | 12:55 |
| mithro | xfxf: You should point thaytan to your script to see if he can see any obivous other problems? | 12:55 |
| xfxf | i did, above | 12:56 |
| xfxf | https://github.com/xfxf/voctomix-outcasts/blob/master/ingest.py#L242 | 12:56 |
| tpb | Title: voctomix-outcasts/ingest.py at master · xfxf/voctomix-outcasts · GitHub (at github.com) | 12:56 |
| cr1901 | mithro: Excellent! | 13:20 |
| mithro | cr1901: Do you want to reset your branch to my code and fix up the comments? Then I can merge it | 13:20 |
| cr1901 | mithro: Sure, except I'm not actually sure what you did :P. Did you accept my pull request, checkout a new branch (hdmi_freq_counter), roll back your master, and then add your new changes to hdmi_freq_counter? | 13:22 |
| cr1901 | Ah, no you didn't accept the pull request. Must've manually made the changes | 13:23 |
| mithro | cr1901: I pulled your change into my repo and then modified it | 13:23 |
| cr1901 | mithro: Okay I see. You removed the C files I added, prob b/c they were not really necessary | 13:25 |
| cr1901 | mithro: Should I include the Opsis changes in the pull request as well? | 13:30 |
| mithro | cr1901: "git remote add mithro https://github.com/mithro/HDMI2USB-misoc-firmware.git; git fetch mithro; git reset --hard mithro/hdmi-freq-counter" | 13:31 |
| cr1901 | mithro: try now | 13:39 |
| mithro | cr1901: Looks like the right things are in your pull request | 13:40 |
| cr1901 | mithro: After you accept, let me know... I accidentally pulled your changes into the wrong branch and need to somehow undo them XD | 13:40 |
| cr1901 | God I hate git... but DVCS is too good to pass up | 13:41 |
| mithro | cr1901: Hrm? | 13:42 |
| cr1901 | mithro: I'm ranting how easy it is to screw up in git. When you accept my pull request, I will somehow need to sync it to master/figure out which commits to remove from my master branch which is now in an inconsistent state | 13:43 |
| mithro | cr1901: I wanted you to do more stuff on the pull request | 13:44 |
| cr1901 | mithro: Oh, nevermind then :P | 13:44 |
| cr1901 | Erm what else do you need? | 13:44 |
| mithro | cr1901: I've left comments on the pull request | 13:50 |
| mithro | cr1901: basically it would be nice to fix up the documentation | 13:51 |
| mithro | cr1901: It would also be nice to have some tests, but I won't hold my breath for that... | 13:51 |
| cr1901 | well I tested this module by combining two boards GPIO; one generating a clock signal at 240MHz, the other receiving it | 13:52 |
| *** ssk1328 has quit IRC | 13:55 | |
| *** rohitksingh_work has quit IRC | 13:58 | |
| cr1901 | mithro: Warning bikeshedding: Is have a separate commit solely for formatting noise for you? | 14:28 |
| mithro | mithro: It's find to add another commit to add documentation? | 14:30 |
| mithro | cr1901: Or are you talking about pep8 formatting fixes? | 14:30 |
| cr1901 | pep8 | 14:31 |
| cr1901 | mithro ^^ | 14:31 |
| mithro | cr1901: Fine for that to be a seperate commit | 14:32 |
| cr1901 | mithro: git seems to think that the HEAD of your repo is after you committed pull request #280. I'm really stumped as to why I can't seem to get the rest of your commits | 14:45 |
| mithro | cr1901: ? | 14:45 |
| mithro | cr1901: Do you know about gitk? | 14:46 |
| cr1901 | Vaguely | 14:46 |
| mithro | cr1901: It lets you see the git history in a nice graphical tree structure | 14:46 |
| mithro | cr1901: makes it easy to see what commits are where | 14:51 |
| cr1901 | mithro: Yea I installed it. Uploading an image now | 14:52 |
| cr1901 | (Netbook was slow) | 14:52 |
| cr1901 | mithro: http://imgur.com/a/X9zzV | 14:54 |
| tpb | Title: Imgur: The most awesome images on the Internet (at imgur.com) | 14:54 |
| cr1901 | This is what git thinks is the current head | 14:55 |
| mithro | cr1901: gitk --all | 14:55 |
| mithro | CarlFK: I'm going to have a couple of things for you to test on an Atlys in an hour | 14:56 |
| cr1901 | Okay, now I see commits from Aug 8 | 14:56 |
| cr1901 | Now what in the world did I do to this poor repo XD? | 14:56 |
| mithro | cr1901: screenshot? | 14:58 |
| CarlFK | mithro: k - give me a 10 min warning, I need to hobble out to my car in the garage | 14:58 |
| CarlFK | did you know I broke my foot (again) | 14:58 |
| mithro | CarlFK: No I did not | 14:59 |
| mithro | CarlFK: I think I fixed the atlys-memtest issue | 14:59 |
| CarlFK | "Acute nondisplaced fifth metatarsal base fracture. Soft tissue swelling. No dislocation" | 14:59 |
| CarlFK | I cracked the long bone that goes to my little toe | 14:59 |
| CarlFK | now I need to make sure I don't break it the rest of the way. so protective boot and crutches. no pain, just a hassle | 15:00 |
| cr1901 | mithro: 2 seconds please | 15:01 |
| cr1901 | mithro: http://imgur.com/a/RePlU | 15:03 |
| tpb | Title: Imgur: The most awesome images on the Internet (at imgur.com) | 15:03 |
| mithro | cr1901: so, "git checkout freq_count" | 15:03 |
| mithro | cr1901: Oh, I also have a lot of branches :P | 15:04 |
| cr1901 | mithro: That's not a horrible thing. It's just that git seems to think a bunch of commits are missing | 15:04 |
| mithro | cr1901: What commits are missing? | 15:04 |
| cr1901 | mithro: Small fixes to output logging | 15:05 |
| cr1901 | mithro: Merge pull request #285 | 15:06 |
| cr1901 | mithro: Adding fifo_depth to HDMI outputs | 15:06 |
| cr1901 | everything on master after "merge #280" | 15:06 |
| mithro | cr1901: Why do you think git things commits are missing? | 15:06 |
| cr1901 | Why aren't these commits showing up when I pull? | 15:07 |
| cr1901 | mithro: Because when I pull, everything is "up to date" as of "merge #280" | 15:07 |
| mithro | cr1901: your master is at the same point as mithro/master | 15:08 |
| mithro | cr1901: If you want to move master to some other point, move it to some other point | 15:08 |
| mithro | cr1901: You also don't have an upstream remote either | 15:08 |
| mithro | cr1901: I recommend doing "git remote add upstream https://github.com/timvideos/HDMI2USB-misoc-firmware.git; git fetch upstream" | 15:09 |
| cr1901 | Oh f*** me... | 15:10 |
| cr1901 | Yea, that's the problem LOL | 15:10 |
| mithro | cr1901: But your master branch isn't all that useful | 15:10 |
| mithro | cr1901: you want to be on the freq_count branch | 15:10 |
| cr1901 | Okay, fixing rectifying that now | 15:11 |
| *** RattusRattus has joined #timvideos | 15:35 | |
| RattusRattus | mithro: oh one last thing before I head out. This is not just OSH projects I see this. The company I work for has similar problems, and right now 26 products of their scandinavion product line have show stopping problems due to tollerance stackup issues caused by letting the factory pick which parts to fit (and it is costing them a fortune and a lot of time to put right) | 15:38 |
| RattusRattus | ttfn | 15:38 |
| mithro | RattusRattus: It's likely I'm going to end up hand soldering these - so I'm not to worried about that bit | 15:39 |
| mithro | RattusRattus: but yeah, I understand it makes difference when you are trying to do larger things | 15:39 |
| RattusRattus | or just go back to them 1 or 2 years later and build a couple more.... | 15:41 |
| CarlFK | mithro: it will make RattusRattus stop talking about it :p | 15:46 |
| CarlFK | RattusRattus: (thank you for talking about it. sounds very reasonable to me) | 15:47 |
| mithro | He is very welcome to send a patch fixing it! :P | 15:48 |
| *** danielki has quit IRC | 15:49 | |
| mithro | two more pull requests to merge before I can head to bed... | 15:52 |
| cr1901 | mithro: Can you show me a docstring example suitable for HDMI2USB> | 15:55 |
| cr1901 | ?* I don't really see any other modules using docstrings | 15:55 |
| mithro | cr1901: https://github.com/m-labs/migen/blob/master/migen/genlib/sort.py#L5 | 15:56 |
| tpb | Title: migen/sort.py at master · m-labs/migen · GitHub (at github.com) | 15:56 |
| mithro | cr1901: just the migen style | 15:56 |
| mithro | cr1901: seems to be this style -> http://hplgit.github.io/teamods/sphinx_api/html/sphinx_api.html | 15:56 |
| tpb | Title: Simple Formatting Rules (at hplgit.github.io) | 15:56 |
| mithro | cr1901: some links to hamster's explaination stuff would be good too | 16:02 |
| cr1901 | mithro: Ack. I'll need to finish later today (if you were waiting for me) | 16:08 |
| mithro | cr1901: Nope - trying to merge some other stuff | 16:29 |
| mithro | CarlFK: There are a bunch of firmware revisions which will land in the prebuilt repo over the next hour or two | 17:08 |
| mithro | CarlFK: can you test them on the Atlys? | 17:08 |
| CarlFK | mithro: yes | 17:09 |
| mithro | CarlFK: v0.0.2-63-g24c11c0 should hopefully fix the memtest problem | 17:10 |
| CarlFK | yay | 17:11 |
| CarlFK | mithro: how many revs? wondering if I should use my autoated tester script or just do 2 or 3 by hand | 17:11 |
| mithro | CarlFK: there are 3 revs which I'd like you to do by hand | 17:11 |
| CarlFK | k | 17:11 |
| mithro | CarlFK: but it would be good to use your autotester script for all the other revisions | 17:12 |
| mithro | CarlFK: If I'm correct, they should be | 17:12 |
| mithro | v0.0.2-63-g24c11c0 <- atlys-memtest-fix | 17:12 |
| mithro | v0.0.2-61-ga02ee1a <- bunch of timing fixes | 17:13 |
| mithro | v0.0.2-41-g00d86be <- fifo adjustments | 17:13 |
| mithro | CarlFK: can you test them properly for ability to record and graphical issues on the inputs/outputs/encoding | 17:14 |
| mithro | CarlFK: I would like to know if you can find any difference between the three | 17:14 |
| mithro | CarlFK: The builds on travis are here -> https://travis-ci.org/timvideos/HDMI2USB-misoc-firmware/builds | 17:14 |
| tpb | Title: Travis CI - Test and Deploy Your Code with Confidence (at travis-ci.org) | 17:14 |
| CarlFK | mithro: maybe. I am not sure I have any hdmi monitors right now | 17:16 |
| CarlFK | I own 8, they all went to PyOhio and I think they are all in the shipping container which has not come back yet | 17:16 |
| CarlFK | but there may be one in my car.. brb may be 10 min... | 17:16 |
| mithro | CarlFK: I'm going to head to bed in a moment | 17:21 |
| CarlFK | k | 17:21 |
| *** rohitksingh has joined #timvideos | 17:23 | |
| *** rohitksingh has quit IRC | 17:28 | |
| *** rohitksingh has joined #timvideos | 17:29 | |
| *** ssk1328 has joined #timvideos | 18:22 | |
| *** danielki has joined #timvideos | 18:23 | |
| *** Bertl is now known as Bertl_oO | 18:34 | |
| *** Bertl_oO_ has joined #timvideos | 18:54 | |
| *** Bertl_oO has quit IRC | 18:54 | |
| *** sb0 has quit IRC | 19:22 | |
| *** danielki has quit IRC | 19:24 | |
| *** rohitksingh has quit IRC | 19:30 | |
| *** Bertl_oO_ is now known as Bertl_zZ | 21:34 | |
| *** ssk1328 has quit IRC | 23:15 | |
| *** cr1901 has quit IRC | 23:55 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!
