ChanServ changed the topic of ##yamahasynths to: Channel dedicated to questions and discussion of Yamaha FM Synthesizer internals and corresponding REing. Discussion of synthesis methods similar to the Yamaha line of chips, Sound Blasters + clones, PCM chips like RF5C68, and CD theory of operation are also on-topic. Channel logs: https://freenode.irclog.whitequark.org/~h~yamahasynths
<TD-Linux>
main limitation is mjpeg and 30fps. but for lots of stuff that's sufficient
<ej5>
i'll give it a try
<cr1901_modern>
Ahh damnit I missed the stream
<doppler>
TD-Linux: what are those strange red cables?
<TD-Linux>
"upgrade picks" are the magewell usb capture devices and flint devices. though the price jump is very large
<doppler>
are those alternative options for self-contained capture devices?
<kode54>
TD-Linux: works under Linux?
<TD-Linux>
yes it appears as a UVC device
<kode54>
right, kind of figured that
<TD-Linux>
doppler, versions of the same device but for phones
<doppler>
why two USB ends, though? are they just wired in parallel?
<TD-Linux>
UVC has an obnoxious downside of all the possible formats being encoded into the descriptor
<TD-Linux>
doppler, extra power
<doppler>
I see
<TD-Linux>
might also be able to charge your phone while using it, I dunno
<TD-Linux>
so all UVC capture devices have to have a framebuffer scaler to scale the input to whatever you actually selected. and they can't enumerate every possible resolution
<TD-Linux>
the magewell and flint have a userspace program to rewrite the descriptors
<doppler>
haha
<TD-Linux>
on my list of someday projects is dedicated retro capture hardware that speaks a non UVC protocol (with linux driver), now that LUNA exists
<ej5>
what's LUNA?
<TD-Linux>
it's a fpga based usb debug device, but the important part is it has usb 2 implementations I can use on a fpga
<ej5>
ah so all the state machines and stuff in the fpga itself
<TD-Linux>
another option is to use a fx2 or fx3 like hdmi2usb.tv / glasgow does, but for this application I like not having to write 8051 code
<ej5>
the fx stuff is...weird
<TD-Linux>
ej5, yes. one of the example projects is a ACM device that just gives you an 8-bit fifo on the fpga side
<ej5>
so...you capture a raw datastream off the video output and then process it in userland?
<TD-Linux>
yes. the main feature I'd like is for it to always follow the input format, pixel perfect
<TD-Linux>
which is allowed by the v4l2 api, so it doesn't even need a special userland driver, just a kernel driver
<ej5>
iirc someone's done something similar but they run a wire to the video card's pixel clock
<ej5>
would you have a PLL and try to lock to the incoming video?
<ej5>
hmm, you could do pretty well by grabbing the full HSYNC pulse, now that i think about it
<TD-Linux>
yes. the OSSC already has all this, so I'm undecided if I'd just leave it to the OSSC or do my own analog front end
<TD-Linux>
there are exactly 2 analog front end chips currently manufactured (3 channel DAC + pll) so there's not a lot of room for "innovation" there
<TD-Linux>
one thing the OSSC lacks is auto clock and phase, which is something that pretty much every LCD has. but I might actually be able to implement it in the OSSC firmware itself
<ej5>
yeah i noticed the thing about the analog front ends. it's really stupid. if you want a generic "video capable" adc you end up paying through the nose because those are only meant for the cable tv market now
<ej5>
ADI basically cornered the market in the US because they got a few fundamental patents
<ej5>
a bunch of their designers left and went to Maxim, designed some parts that were a bit too similar. lawsuits happened.
<TD-Linux>
apparently the next OSSC is going to use the renesas part
<TD-Linux>
ej5, also annoying is that those chips are also the only way to get a video PLL IC (that can do 15kHz -> 6Mhz etc)
<ej5>
i want to find the one from a chinese company
<TD-Linux>
(with the exception of the renesas 9173B)
<cr1901_modern>
Not saying it's ideal, but can't you make your own PLL at the desired freq at freqs that low. Also, 6MHz is within both Spartan 6 and ice40 tolerances
<TD-Linux>
with discrete components yes
<TD-Linux>
15khz is far too low for a fpga pll to lock on to
<cr1901_modern>
The VCO would be running at 6MHz, but the 15khz may still be too low- Idk :P
<TD-Linux>
yes
<TD-Linux>
I haven't found a non-CD4046 pll ic that can track 15kHz, for that matter
<cr1901_modern>
Do you want to track 6MHz or 15KHz (because the way you made it sound you want to do freq multiplication)?
<andlabs>
what is this for?
<TD-Linux>
analog video capture
<TD-Linux>
I also have a secondary CRT related application
<cr1901_modern>
Anyways in your position I would make a discrete one
<kode54>
I have an analog video capture device, but it's obsolete now
<kode54>
it's a USB device with proprietary drivers
<kode54>
the drivers exist in two forms
<kode54>
a Windows driver that probably won't work on anything newer than 7 or possibly XP
<kode54>
and a macOS driver that requires QuickTime, and therefore will only work on Mojave or older
<ej5>
CD4046 has some variants that are a bit better