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
ej5 has quit [Read error: Connection reset by peer]
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
<kode54>
andlabs: think we'll ever be welcome back on badnik? or are you even there any more?
<cr1901_modern>
Is Sonic Retro still full of elitists that take themselves too seriously and Twe*ker apologists?
<cr1901_modern>
Wait... I just remembered that badnik isn't _just_ the Sonic Retro server...
Xyz_39808 has quit [Ping timeout: 245 seconds]
Xyz_39808 has joined ##yamahasynths
l_oliveira has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]
<andlabs>
hell it isn't even that anymore
<andlabs>
but I don't know
cr1901_modern has quit [Ping timeout: 268 seconds]
cr1901_modern has joined ##yamahasynths
* cr1901_modern
sighs
<cr1901_modern>
My hard drive and/or laptop is falling apart it seems.
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined ##yamahasynths
Xyz_39808 has quit [Ping timeout: 250 seconds]
<Lord_Nightmare>
badnik is also used by tcrf
<Lord_Nightmare>
or is that now its primary purpose?
<cr1901_modern>
AFAIK, it's always been X's server, so likely it's mostly tcrf. I could ask them if I wanted.
<ValleyBell>
badnik runs a few channels I'm in. I always stayed away from the "retro" channel though as it has a reputation for being drama-only and I really don't need that.
<ValleyBell>
(Also, I helped T. some years ago with a small project and he's a nice person.)
<ZirconiumX>
Morning
<cr1901_modern>
Who is T?
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined ##yamahasynths
<KitsuWhooa>
ValleyBell: I have the cm-32p in my hands :p
<KitsuWhooa>
Haven't opened it yet because I happen to be at uni
<KitsuWhooa>
But yeah
<cr1901_modern>
ValleyBell: I sent you payment insns. I am afk for now, so if you have q's, complaints, flames, yell in privmsg
<KitsuWhooa>
Right, it doesn't seem damaged externally in any way
<KitsuWhooa>
Although, screw you Roland for putting a centre negative DC jack :p
<KitsuWhooa>
also one of the rubber feet is missing; Thought I'd mention it
<protosphere>
centre negative seems pretty common for japanese equipment of the era at least
<KitsuWhooa>
I know the megadrive 1 and the early game gears are centre negative too
<KitsuWhooa>
but yeah
<KitsuWhooa>
oooh there's a dead bug inside :p
<KitsuWhooa>
t̶i̶m̶e̶ ̶t̶o̶ ̶s̶t̶a̶r̶t̶ ̶g̶d̶b̶
<KitsuWhooa>
also fwiw, ValleyBell, it didn't come with a power supply
<KitsuWhooa>
idk if it was supposed to, but I don't have one
<KitsuWhooa>
and it looks like someone else may have been in it before? There are some dark fingerprints on the metal shielding
Patater_ has quit [Quit: Explodes into a thousand pieces]
Patater has joined ##yamahasynths
<KitsuWhooa>
Hm, someone has definitely been in this before, and it looks like they replaced/reworked the DIN connectors
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [Client Quit]
<cr1901_modern>
KitsuWhooa: Excellent work. The person who paid for the auction/to have it shipped said he was happy to help and hopes the imaging is successful.
<KitsuWhooa>
thanks :p
<KitsuWhooa>
I'm currently on the second mask rom
<cr1901_modern>
I guess ValleyBell is at work, but he'll be happy to hear this too
<KitsuWhooa>
indeed
andlabs has joined ##yamahasynths
<Sarayan>
You're dumping the mask roms? Excellent
<Sarayan>
btw, is it a midi input or is it something like isa/pci?
<KitsuWhooa>
DIN midi in
<cr1901_modern>
The auction showed an enclosure
<Sarayan>
cool
<KitsuWhooa>
yeah, it's external
<Sarayan>
so it's a rompler like we love them
<Sarayan>
cpu?
<cr1901_modern>
I don't think an ISA card would fit that form factor :P
<cr1901_modern>
So it's an evolution of 8051 -> 8098, like 8048 -> 8051?
<Sarayan>
d110, mt32, sc55
<Lord_Nightmare>
also remember the mt-32 uses the 16-bit bus 8094 cpu, but the cm-32l, cm-32p(?) and lapc-i all use the 80198 which uses an 8 bit bus
<Lord_Nightmare>
and roland never properly fixed their cycle timed mt-32 code for the slower cpu bus so some stuff just doesn't work right on the later devices
<Sarayan>
not cm32p
<KitsuWhooa>
pretty sure this is a 16 bit cpu
<Sarayan>
as KW just said :-)
<KitsuWhooa>
:p
<Lord_Nightmare>
ah
<KitsuWhooa>
the eprom is definitely 8 bit though
<KitsuWhooa>
AM27C512
<Lord_Nightmare>
so cm-32p is using an 80196?
<Lord_Nightmare>
if it has just one firmware eprom, its using an 8-bit bus cpu
andlabs has quit [Read error: Connection reset by peer]
andlabs has joined ##yamahasynths
andlabs has quit [Ping timeout: 250 seconds]
Xyz_39808 has joined ##yamahasynths
andlabs has joined ##yamahasynths
<superctr>
<ValleyBell> badnik runs a few channels I'm in. I always stayed away from the "retro" channel though as it has a reputation for being drama-only and I really don't need that. <- #retro is pretty much dead now since all the drama went to discord
<superctr>
really both of the channels on badnik that i still have in autojoin are really just bots. it's a little sad, i think
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
<ValleyBell>
Sarayan: Didn't one of you have a tool for decoding MT-32 sample data?
<KitsuWhooa>
seems to be underrunning every now and then?
<ValleyBell>
I have a feeling that my Gentoo installation might be a bit screwy.
<ValleyBell>
I expect it to underrun like once or twice during the whole stream, because I have pretty low buffer sizes set.
<ValleyBell>
(makes controlling it nicer when streaming MIDIs to my workplace)
<KitsuWhooa>
it's underrunning like every 10 seconds I'd say
<ValleyBell>
hmm :/
<ValleyBell>
What bothers me most is that I hear clicks every now and then
<KitsuWhooa>
Yeah, I'm hearing them too :p
<ValleyBell>
despite having the speakers connected to the audio interface directly
<KitsuWhooa>
oh
<KitsuWhooa>
wait, USB? :p
<ValleyBell>
yeah
* KitsuWhooa
has never ever managed to get realtime audio working over usb
<ValleyBell>
The interface is USB. But the SC-55 is connected directly to it and the speakers are connected to its "mixer output"
<ValleyBell>
so the PC shouldn't interfere
<KitsuWhooa>
Well, I hear clicks much more often than you do, no?
<KitsuWhooa>
so it could be two issues :p
<ValleyBell>
I *know* that there is a micro buffer loss every 15 seconds or so
<cr1901_modern>
KitsuWhooa: AIUI: Supposedly isochronous is good for audio, but 1. Nobody implements iso correctly, and 2. Like UDP it has fallen out of favor for taking the RISK of non-realtime delivery over bulk?
<ValleyBell>
it loses about like 30 samples then
<KitsuWhooa>
cr1901_modern: all audio over usb uses iso
<whitequark>
you can certainly implement iso correctly
<cr1901_modern>
whitequark: I meant the vendors, not you :P
<KitsuWhooa>
I don't think it's an iso issue, rather usb being terrible
<KitsuWhooa>
:p
<whitequark>
cr1901_modern: i never implemented iso
<ValleyBell>
and for some reason it works properly (no buffer loss) when recording using DAWs, but not using arecord
<KitsuWhooa>
my usb audio experience on linux can be summed up as constant clicks, and on windows constant pitch bending to make up for the buffer loss
* KitsuWhooa
shrugs
<whitequark>
oh god you just made me realize that something i experienced a long time ago was *not* a hallucination
<whitequark>
not usb-related, bluetooth rather
<whitequark>
which is even more evil
<KitsuWhooa>
speaking of sound cards
<cr1901_modern>
On Windows, Bluetooth, WHEN IT WORKED, was constant BSODs for me
<KitsuWhooa>
cr1901_modern: sounds more like a dodgy driver
<ValleyBell>
LOL
<cr1901_modern>
A driver is an essential component of Bluetooth working :)
<cr1901_modern>
(yes, it was of course the driver)
<ValleyBell>
Those Chinese USB-MIDI cables have a 100% chance of BSODing Windows 2000.
<KitsuWhooa>
I'm saying it's not bluetooth's fault though
<KitsuWhooa>
people use win2k? :p
<cr1901_modern>
The driver has to implement talking to the device over bluetooth. How much does Windoze abstract away?
<ValleyBell>
I have an old PC with Win95 and Win2k on it
* cr1901_modern
grasps at straws
<ValleyBell>
and I wanted to try doing 2-Port MIDI
<cr1901_modern>
whitequark: Oh, I thought you did implement iso for a Glasgow experiment
<KitsuWhooa>
I think interrupts would be good enough™
* Sarayan
waves
<KitsuWhooa>
cr1901_modern: the reason I said that is because a bad usb driver can cause a bluescreen too. It's not USB's fault though :p
<KitsuWhooa>
it's not something specifically bad about the protocol causing it, is I guess what I am trying to say
<ValleyBell>
I have one SB16 in it and one USB MIDI cable. So the procedure was: plug in the USB-MIDI-cable, driver installation starts, BSOD
<cr1901_modern>
True...
<Sarayan>
ValleyBell: Sounds rather traditional
<ValleyBell>
And it was the generic USB-MIDI driver.
<KitsuWhooa>
don't the nobrand chinese stuff usually come with a mini cd that has their own driver? :p
<ValleyBell>
that one didn't
<KitsuWhooa>
ah :p
<ValleyBell>
It also produces bugs on Win7.
<KitsuWhooa>
A protocol I'll blame for being shit though is MTP, but that's another story :p
<ValleyBell>
Open the USB-MIDI device, play something, close the device, reopen it, send some event -> program freezes and can't be killed by task manager.
<KitsuWhooa>
and I thought that stuff only happened on linux :p
<ValleyBell>
They finally fixed that in Win10.
<KitsuWhooa>
I can hardlock the floppy driver on my computer very easily, and it requires a reboot afterwards
<KitsuWhooa>
it's a huge pain when you're trying to rip floppies that are in not so great condition
<ValleyBell>
I can imagine ...
<KitsuWhooa>
<KitsuWhooa> I can hardlock the floppy driver on my computer very easily, and it requires a reboot afterwards <-- application reading gets stuck waiting for IO and you can't kill it
<KitsuWhooa>
whitequark: I have thanks to ZirconiumX :D
<Sarayan>
KitsuWhooa: At that point linux is way more stable driver-wise if only because there are no drivers by thrid zone devs
<Sarayan>
Hi wq
<KitsuWhooa>
Sarayan: you'd be surprised :p
<whitequark>
hi Sarayan
<KitsuWhooa>
For some stupid reason my laptop when booted to linux can't read CDs. It just throws constant IO errors
<KitsuWhooa>
reboot to win98se and it works on first try
<ValleyBell>
fun fact: My laptop doesn't boot *at all* when my USB audio interface is connected.
<KitsuWhooa>
Ah yes, crappy bios
<ValleyBell>
The BIOS doesn't like it.
<KitsuWhooa>
one of the reasons i have my desktop 24/7 is because my corsair keyboard makes the bios hang during POST
<KitsuWhooa>
:p
<KitsuWhooa>
and it's a nightmare to get it to boot
<ValleyBell>
It just gets stuck and turns off after a while.
<ValleyBell>
awww..
<ValleyBell>
and now try getting into the BIOS menu
<KitsuWhooa>
other times I need to replug the PS/2 keyboard
<ValleyBell>
I still have a PS/2 keyboard plugged into my computer :P
<KitsuWhooa>
I do too
<KitsuWhooa>
it's more of a necessity for me though :p
<whitequark>
20:00 < ValleyBell> fun fact: My laptop doesn't boot *at all* when my USB audio interface is connected.
<ValleyBell>
It's fun combining old and new stuff in one PC.
<whitequark>
wow
<whitequark>
i have this with thunderbolt
<whitequark>
i thought they fixed all the usb bugs
<ValleyBell>
Well, the laptop is from 2010.
<Sarayan>
thunderbolt.... fixed all the bugs?
<KitsuWhooa>
<ValleyBell> It's fun combining old and new stuff in one PC. <-- it's why I don't want to upgrade my desktop. I don't want to lose my floppy controller or my PCI slots :p
<ValleyBell>
My PC (mainboard from 2017) doesn't mind.
<KitsuWhooa>
or my PATA controller for that matter
<ValleyBell>
Oh yeah, the only thing I miss about my PC is the floppy controller.
<KitsuWhooa>
I wish usb floppies were more reliable
<ValleyBell>
But I still have 2 PCI slots (which are fill with a YMF744 and an SB Audigy, the latter I haven't used since I got the audio interface)
<KitsuWhooa>
maybe you should switch back to the audigy for the streams :p
<KitsuWhooa>
that one didn't click
<ValleyBell>
I used the onboard-audio for that, actually.
<KitsuWhooa>
oh, even better =p
<ValleyBell>
because I ... think I didn't get the Line In to work.
<ValleyBell>
I forgot whether it was the YMF or the Audigy. For one of them I could only get Mic In to work.
<ValleyBell>
I actually might switch to alternative ways of capturing for future streams.
<ValleyBell>
btw, I tried one of those USB floppy adapter things once. (so I could connect the actual floppy device to USB) It didn't work very well at all.
<KitsuWhooa>
if I have to get rid of my floppy, I'll just use my laptop's over the network
<ValleyBell>
It could read usual 1.4 MB disks, but I tried a 700 KB disk once and it work.
<cr1901_modern>
Yup you'll get an obfuscated binary you have to decompile your- oh, nevermind
<KitsuWhooa>
decomwhat? :p
<Lord_Nightmare>
the problem with it is it has one line of code borrowed from MUNT in there, so it has to be licensed gplv2, but the line is entirely math and can you even copyright that?
<ZirconiumX>
I think you're fine here :P
<Lord_Nightmare>
so if you can't copyright math, then technically its 3bsd
<ZirconiumX>
I think this falls under fair use
<KitsuWhooa>
IANAL
<KitsuWhooa>
:D
<KitsuWhooa>
something for the future: la32_sampleparse.c:107:10: warning: variable ‘expDeltaTable’ set but not used [-Wunused-but-set-variable]
<KitsuWhooa>
:p
<KitsuWhooa>
Hm, I ran it but ow my ears :p
<ValleyBell>
maybe you need to byteswap the ROM
<superctr>
<Lord_Nightmare> the problem with it is it has one line of code borrowed from MUNT in there, so it has to be licensed gplv2, but the line is entirely math and can you even copyright that? <- no
<KitsuWhooa>
ValleyBell: oh I read that the program swaps it
<ValleyBell>
MAME ROMs are very often byteswapped so that strings are unreadable
<superctr>
if it would be something like that then every single trivial algorithm like ADPCM would infringe copyrights
<ValleyBell>
but in your dump they *are* readable
<KitsuWhooa>
oh interesting :p
<superctr>
if you want to byteswap
<Lord_Nightmare>
the program reads the pcm ROM as a big-endian 16 bit ROM packed into an 8 bit ROM
<KitsuWhooa>
Hm, even after byteswapping I get garbage. Interesting
<superctr>
i would probably rewrite that entirely with integer math, generally FP math should stay out of emulation unless the hardware itself is FP
<Lord_Nightmare>
whats really weird is the way the la32 actually does its pow(2,n) stuff on die
<Lord_Nightmare>
it has two exp lookup tables
<superctr>
that is probably faster than a big multiply unit
<superctr>
so it makes sense
<Lord_Nightmare>
and i think i discussed with sarayan at some point what they were doing
<Lord_Nightmare>
the tables are not copyrightable on the la32 die
<superctr>
using logarithm space for multiplication makes it much faster and it does make sense HW-wise
<Lord_Nightmare>
in fact that program has code in it to generate all 3 of the die tables: the sine table (which is not relevant here) and the two exp tables
<Lord_Nightmare>
but i haven't yet figured out how to accurately generate all the derived bits from the two exp tables
<KitsuWhooa>
I wonder if I somehow need to combine the three sample roms together
<KitsuWhooa>
I guess I can see how they are connected, but effort :p
<superctr>
yeah, i reversed some exp tables for a sound driver a while ago, i couldn't get it 1:1 accurate, but when i plot them and compare them visually, they are basically identical
<superctr>
some of the LSB bits were inaccurate, i tried fiddling with decimals but that eventually didn't work
<superctr>
probably in some cases i assume the programmers just used using an old calculator with limited accuracy
<Lord_Nightmare>
apparently it does some sort of clever approximation/interpolation to get 15 or 16 bits of resolution out of an exp table that's only 512 entries long and i think 12 or 13 bits wide?
<superctr>
impressive if it's not linear interpolation
<Lord_Nightmare>
the key is that delta value, where it stores the difference between adjacent entries
<Lord_Nightmare>
so whatever math its doing needs to be done fast enough that it doesn't have time for a second ROM access to manually caluclate exp[n] - exp[n-1]
<superctr>
i reversed a sound driver with a soft-LFO, where the lookup table for each sample contained the sample value and the delta for interpolation
<superctr>
it's actually kinda nice as it means the same code can be used for different kinds of waveforms, you just change the table
<superctr>
you won't get linear interpolation artifacts if you want a perfect saw or sqaure wave for example
<cr1901_modern>
why would you need to interpolate to create "soft-LFO"? Do they not store the LFO samples at the same sampling freq as the standard waveform?
* cr1901_modern
probably doesn't understand this at all
<superctr>
software LFO
<superctr>
it only updates during the sound driver's update interval
<cr1901_modern>
why do you need to interpolate?
<KitsuWhooa>
Don't worry, I don't understand any of this :D
<cr1901_modern>
as opposed to "add the value of the LFO at the given sample"
<superctr>
you can adjust the frequency and depth
<superctr>
so it would sound a bit jarred at high depth and low frequency
<cr1901_modern>
ahh, well even linear interp would help you there I bet
<superctr>
it's a quite powerful LFO algorithm, and then you have another lookup table pitch envelope on top of that
<cr1901_modern>
Do you have source code and/or a document of findings I could look at?
<cr1901_modern>
If an isochronous IN xfer fails (wasn't received properly, bad CRC if one is sent), is there any way to indicate to the user application that the xfer failed?
<cr1901_modern>
(e.g. with libusb)
<KitsuWhooa>
no idea about libusb, sorry
<KitsuWhooa>
I may be a usb dev, but I rarely use libusb
<cr1901_modern>
13 bits/sample * 2 channels * 62500 samples per second = minimum of 1625000 bits per second of bandwidth required for real time capture of a YM2151 (4 MHz clk)
<cr1901_modern>
Worth it to use bulk and possibly eat the cost of a failed xfer, or use iso and bail if any packet was received improperly?
<cr1901_modern>
(Oh and it would be 32 bits in practice because you can't send fractions of a byte)
<KitsuWhooa>
IIRC latency isn't guaranteed with bulk
<KitsuWhooa>
if it doesn't matter for your use case, go ahead :p
<cr1901_modern>
I don't care about latency if it's bounded
<KitsuWhooa>
Is there any reason you aren't just implementing an hid sound device in the first place? :p
<cr1901_modern>
hid only had bandwith up to 64000*8 kbps
<cr1901_modern>
not enough
<KitsuWhooa>
oh, I thought you were sending audio
<KitsuWhooa>
I just re-read
<cr1901_modern>
oh no, I wanted raw samples, the idea of doing black box RE (not that that hasn't been done before)
<cr1901_modern>
and YM2151 was a contrived example b/c I could tell you the bandwidth required immediately
<whitequark>
bulk doesn't have bounded latency
<cr1901_modern>
then iso it is... I know packets aren't retried, but does the host at least have a way to communicate an xfer failure occurred? I can live with captures failing due to an occassional packet send failure.
<cr1901_modern>
communicate an xfer failure occurred up to a user application*
<whitequark>
nope
<whitequark>
there is no acknowledgement on wire
<cr1901_modern>
great, then that doesn't work either. When receiving from device, I need to be _pretty_ confident that buffer index 0 is the first sample, index 1 is the second sample, etc
<whitequark>
yep, usb sucks
<KitsuWhooa>
^
<whitequark>
use bulk and hope nothing breaks
<whitequark>
except things WILL break
<cr1901_modern>
I don't hate USB. But it's a shame it doesn't seem to fit my needs here.
<cr1901_modern>
I could prob use heuristics to detect when a sample was missed
<whitequark>
use two interrupt endpoints
<whitequark>
and split the buffer
<whitequark>
or something
<cr1901_modern>
but that also technically doesn't have unbounded latency? If each packet has to be redelivered, that's 8 bytes/2 32-bit samples of latency introduced. Certainly preferable to bulk tho.
<KitsuWhooa>
<cr1901_modern> I don't hate USB. But it's a shame it doesn't seem to fit my needs here. <-- that's because you haven't written enough code for it :D
<whitequark>
you can't actually win with sb
<whitequark>
*usb
<whitequark>
but
<whitequark>
interrupt endpoitns reserve the bandwidth
<KitsuWhooa>
I'll just quote this quote
<KitsuWhooa>
<NiGHTS> Quote #66: "Beware: it is impossible to simultaneously understand and appreciate USB." (added by ZirconiumX at 01:27 PM, February 14, 2018)
<Ultrasauce>
just use isochronous transfers they always work well right
<whitequark>
so you only really have to care about failed transmissions
<cr1901_modern>
Ultrasauce: I would need an xfer to fail to be reported
<TD-Linux>
cr1901_modern, if you can do redeliveries out of order the latency can be manageable
<cr1901_modern>
failing the whole capture b/c an xfer failed is acceptable
<cr1901_modern>
to me*
<TD-Linux>
you could use rtp style sequence numbers. or straight up rtp
<cr1901_modern>
TD-Linux: is this for ISO?
<cr1901_modern>
err isosynchronous*?
<cr1901_modern>
>RTP typically runs over User Datagram Protocol (UDP)
<cr1901_modern>
Yes, yes it would be
<KitsuWhooa>
that sounds good, actually
<cr1901_modern>
But each failed xfer means a full packets worth of latency, correct?
<whitequark>
isochronous
<whitequark>
not isosynchronous
<KitsuWhooa>
cr1901_modern: it depends on how you handle it
<cr1901_modern>
how does out-of-order redelivery reduce latency (since if we have to RE-deliver, we already know a transaction failed)?
<whitequark>
you don't hae to stop and wait
<cr1901_modern>
I think I misunderstand something about isochronous... it's not fixed bandwidth like interrupt?
<cr1901_modern>
i.e. "one xfer per each new SOF"
<whitequark>
it is
<whitequark>
but you can have more than one
<cr1901_modern>
ahhh, then that makes TD-Linux's approach workable. I could also open a low bandwidth IN interrupt EP whose sole purpose is to indicate "the device's buffers are filled due to excessive failed xfers, stop the xfer".
<whitequark>
you can't detect failed interrupt xfers unless you maintain some sort of counter
<whitequark>
which you might
<cr1901_modern>
doesn't matter in my case, if the device's buffers are filled that's unrecoverable. So the int endpoint would just keep sending until it got an ACK from host
<whitequark>
how do you define a "failed transfer" then
<whitequark>
oh nvm
<whitequark>
yeah i guess that works
<cr1901_modern>
Do iso xfers not even receive an ACK from host?
<cr1901_modern>
shit... no, it doesn't
<cr1901_modern>
but UDP has no guarantee of delivery either, and RTP is used on top of that...
<Ultrasauce>
rtp is used alongside rtsp for synchronization and retransmission requests etc
<TD-Linux>
*rtcp
<Ultrasauce>
yes
<Ultrasauce>
rtsp is the cursed tcp one right
<TD-Linux>
rtsp is a higher level protocol to start and stop rtp streams
<Ultrasauce>
oh yes i was thinking of rtmp...
<cr1901_modern>
Well with RTP, the receiver knows if there was packet loss, but not the transmitter
<Ultrasauce>
what an intuitive set of acronyms
<TD-Linux>
cr1901_modern, yup, so you send periodic rtcp messages back
<cr1901_modern>
so I need an interrupt OUT endpoint for that
<cr1901_modern>
(I said IN, but that was before I realized that iso has no ACK)
<cr1901_modern>
Actually no... it needs both an IN and OUT
<KitsuWhooa>
Can you not have a buffer larger than needed on your device and then when there's a missed packet based on the counter just ask it through the OUT endpoint to resend the iso?
<KitsuWhooa>
or maybe I'm missing something
<cr1901_modern>
I think that's what TD-Linux is suggesting
<cr1901_modern>
or do you mean use the OUT iso endpoint?
<KitsuWhooa>
No, OUT interrupt
<KitsuWhooa>
so that you can tell the device what to resend
<cr1901_modern>
yea, that's what I was trying to say
<KitsuWhooa>
I wouldn't trust a control to ep0 in this case to make it there in time
<cr1901_modern>
but there should also be an IN interrupt so the device can say "f*** this I give up"
ej5 has joined ##yamahasynths
<KitsuWhooa>
can it not do it through the iso? Or just stop sending data altogether?
<whitequark>
this is so cursed
<whitequark>
what application is this for anyway
<whitequark>
if you're finew ith stopping the entire transfer on overflow you can just use bulk
<whitequark>
glasgow does that
<cr1901_modern>
>(5:11:17 PM) cr1901_modern: 13 bits/sample * 2 channels * 62500 samples per second = minimum of 1625000 bits per second of bandwidth required for real time capture of a YM2151 (4 MHz clk)
<cr1901_modern>
>(5:12:13 PM) cr1901_modern: Worth it to use bulk and possibly eat the cost of a failed xfer, or use iso and bail if any packet was received improperly?
<cr1901_modern>
whitequark: I'm not actually committing to, well, anything. I'm just mulling ideas around. Bulk is probably fine. But I kinda want to play with iso.,
<cr1901_modern>
KitsuWhooa: RTP has provisions for packet types. So yes, that can be used in place of int IN. And missed xfers don't matter there because that type of failure is unrecoverable.
<KitsuWhooa>
I was thinking, the device doesn't need to tell the host if it can't recover lost data
<KitsuWhooa>
it can just abort
<KitsuWhooa>
if you don't care about lost data, then you won't be implementing this thing in the first place
<cr1901_modern>
True. "So why not just use bulk?"
<cr1901_modern>
Bulk probably works fine :P
<KitsuWhooa>
because it's higher latency, no? :p
<KitsuWhooa>
isn't that the whole point you were looking at isochronous transfers?
<cr1901_modern>
Yes, because latency == buffers filling up earlier
<cr1901_modern>
device buffers*
<cr1901_modern>
and my theory is I can get the longest captures by using iso with some "simple" protocol on top to handle the case where xfers failed and need to be retried.
<cr1901_modern>
this only works of course if a USB link is reliable and most xfers succeed.
<KitsuWhooa>
so it's basically unpredictable latency vs predictable latency but with failure :p
<cr1901_modern>
Isn't that the crux of bulk vs iso :P?
<KitsuWhooa>
yes, but iso doesn't abort on loss, which is what you want to do or something
<KitsuWhooa>
I don't know, I have no idea what's going on anymore =p
<cr1901_modern>
I need "low latency, high bandwidth xfers, with reasonable guarantee that all data xfers _eventually_ succeed"
<cr1901_modern>
there is nothing in USB that provides all 3.
<KitsuWhooa>
pick your poison, basically :p
<cr1901_modern>
But my guess is ISO with a way to retry comes closest
<cr1901_modern>
And again, I'm just mulling over ideas. Is it wrong to mull over cursed ideas if I don't presently intend to commit to them :P?
<KitsuWhooa>
nope
<cr1901_modern>
whitequark: While it's on my mind... does fx2lafw use bulk or ISO?
<whitequark>
bulk
<whitequark>
iso has bw restrictions
<whitequark>
that bulk doesnt
<cr1901_modern>
ahhh right. Anyways, that driver is pretty good- from the little I've looked into it, it's doing a DMA xfer every cycle, but Idk how it handles bulk having to retry
<cr1901_modern>
Unless it relies on 24 MHz at 8 bits being just a tad slower than 480 Mbps
<cr1901_modern>
so there's breathing room
<whitequark>
24*8=192
<whitequark>
also, fx2lafw handles it quite badly
<whitequark>
or rather, sigrok
<TD-Linux>
afaik it can't retry because it's using the fx2's fifo and not caching to ram
<TD-Linux>
in my experience if you actually start getting packet loss on USB a lot of peripherals and drivers just fall over
<whitequark>
yes
<TD-Linux>
using a USB webcam on a car with a long cable was a great way to hardlock the linux kernel
<cr1901_modern>
sigrok w/ fx2lafw has worked well in my experience... it's not perfect of course.
<whitequark>
it drops capture constantly
<whitequark>
at higher rates
<cr1901_modern>
if it's attached to a hub, yes that matches my experience.
<cr1901_modern>
attached directly to the host controller I get pretty consistent capture
<TD-Linux>
fwiw if you run into fx2lafw limits the hantek 4032l has a decent sigrok driver
<cr1901_modern>
it's also 8 times more experience than a saelae clone :P
<TD-Linux>
ej5, while we are off topic it turns out I'm making a monitor and was looking at your previous psu and magnetic deflection circuits. any hot tips for the second time around?
<ej5>
yeah i saw your tweets about it. you've gone a little further than i have, my focus is mainly on vector amplifiers
<ej5>
the hot tip would be to compensate your deflection coil inductance with a parallel RC network
<ej5>
it's a little like the snubber network in a switching power supply.
<TD-Linux>
ej5, ah okay I saw the parallel RC network in some monitors, but I couldn't get it to do much for me
<TD-Linux>
though maybe now that I have the in loop compensation as well it will work better
<TD-Linux>
also for your 1kv supply did you consider using any of the camera flash ics?
<ej5>
in parallel with the deflection coil is easier for the driver circuit
<ej5>
flash circuits aren't really designed for continuous duty. my circuit is derived from a jim williams CCFL driver circuit
<TD-Linux>
ah I see. in my case my eht is from a flyback, but I still need ~800v for g1/g2.
<cr1901_modern>
This isn't the color code reference I learned
<cr1901_modern>
Admittedly the mnemonic I learned is absolutely horrible
<cr1901_modern>
(It ends with "But Violet Gives Willingly")
<cr1901_modern>
But where's orange?
<ej5>
orange is NAMED AFTER A FRUIT
<cr1901_modern>
(n.b. I have no one to blame but myself for committing that nmemonic correctly)
<cr1901_modern>
Idk about ya'll but I think this is a shitpost
<cr1901_modern>
:D
<ej5>
it's on my profile: vacuum tubes, vintage computers, the MOnSter6502, memes, and other detritus
<ej5>
^ memes
* cr1901_modern
tries to remember the last meme he actively participated in
<cr1901_modern>
"Just Monika"?
<cr1901_modern>
that's kinda obscure
<TD-Linux>
ddlc is mainstream now
<cr1901_modern>
Is it really?
<cr1901_modern>
TD-Linux: You're prob right, I just wish ppl would stop trying to cash in on the "ironic VN" craze.
<whitequark>
ddlc
<whitequark>
?
<ej5>
ironic VN?
<TD-Linux>
doki doki literature club
<cr1901_modern>
ej5: A popular view of visual novels in the west is that they are "silly games by those wacky JP developers", and it's been a trend to make visual novels whose sole purpose is to be wacky and make fun of the genre, like the KFC one.
<ej5>
visual novels=graphic novels?
* ej5
was never into the weeb shit ;)
<cr1901_modern>
And you are a much better person for that :)
<cr1901_modern>
Visual novel is a game genre, thinking of it as a graphic novel with animated text and limited moving pictures: https://en.wikipedia.org/wiki/Visual_novel
<cr1901_modern>
oh and choose-your-own-adventure built-in to most of them