<whitequark>
i could probably just add iso to python-libusb1
<tnt>
And it was more about the 'isoc' support in python in general than this particular applet case, just because I remembered having used it not so long ago and I wanted to know if I was loosing my mind :p (sometime I remember stuff that never happenned ... getting old)
<whitequark>
ah
<whitequark>
i have the opposite problem: i constantly forget stuff that has happened
<whitequark>
... like yesterday, or a week ago, or 1 minute ago
<tnt>
:/ that doesn't help either.
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjQV2
<_whitenotifier-3>
[GlasgowEmbedded/Glasgow] whitequark c2b99cc - applet.audio.dac: prevent sampling clock drift due to divider error.
<whitequark>
scheduling errors and clock drift.
<whitequark>
clock drift is kind of a hard problem
<tnt>
Yeah, I had to implement excplicit feedback endpoint in a design where I have similar requirements.
<whitequark>
tnt: so what i'd make
<whitequark>
is a DPLL
<whitequark>
just lock onto the incoming signal
<whitequark>
use a fractional-N NCO
<___blasty>
can I buy a assembled revC somewhere yet?
<whitequark>
unfortunately no
<tnt>
whitequark: Indeed, here you have the advantage you are the clock master. In my case, I had to follow an externally forced timing from the other party.
<whitequark>
ahh
<whitequark>
yeah I now see that UAC allows this.
<whitequark>
"implicit feedback"
<tnt>
yup the mechanism described in USB works fine, but there is still a remark somewhere that says that you also need to bias the feedback depending on your FIFO level to fix long term drift.
<whitequark>
actually, that is exactly how i would make my DPLL
<whitequark>
what is it describing then if not that?
<tnt>
basically measure the number of 'sample clock' between N USB SoF packets.
<tnt>
but you can have exceptional events (lost packets for instance) that will need to be compensated for other than just counting hte number of sample clock.
<tnt>
(and any measurement imprecision you might have)
<tnt>
5.12.4.2 in the usb spec. (and that remark is the very last paragraph of this section)
<whitequark>
ohh i see
<whitequark>
this is actually more complex than a bang-bang DPLL with comparator of FIFO level adjusting frac-N NCO by 1 LSB.
<whitequark>
and works worse, apparently?
<whitequark>
leave it to USB to make something more complex and work worse.
<tnt>
Well, the description makes it look weird and complex, but the reality is actually quite easy to implement. Just count how many samples you consumed in the last measurement interval, add a small offset if you're above/below your optimal fifo level and send that to the host. The host when filling packets will send that many samples in the next N packets.
<whitequark>
ahhh i see
<whitequark>
wait
<whitequark>
oh i see, so you basically spread the DPLL across the host and the device for explicit feedback case, right
<whitequark>
so the host has to run a resampler to adjust to your clock.
<whitequark>
and what i'm describing is a case where the device changes its own sample rate to adjust to the host's clock.
<whitequark>
yeah makes sense
<tnt>
Yeah, you're in what they describe as the "Adaptive Sink" I think. And I was in "Asynchronous Sink" case.
<whitequark>
yep
<whitequark>
marcan: poke
<marcan>
whitequark: seriously fuck php
<marcan>
and yeah
<marcan>
so remind me again what I should be working on
<whitequark>
uhhh, something about git tags
<marcan>
ohh that
<marcan>
got it
<marcan>
(still busy the next few days, but not "holy shit deadline for big things" busy, so I'll find time)
<whitequark>
well there's probably more :p
<whitequark>
ahh ok
<marcan>
at $work right now, putting it on my mental list. feel free to bug me if I forget.
<whitequark>
ack
<marcan>
aside: might use the revB as a prototyping board for an I²S-to-ADAT converter, interested in having both of those chunks as applets? (I²S input and ADAT output, should be trivial to make them independent)
<whitequark>
sure, why not
<whitequark>
wtf is ADAT
<marcan>
ADAT Lightpipe specifically
<marcan>
(ADAT is a tape thing)
<marcan>
8 channel 24bit audio over the TOSLINK physical layer
<whitequark>
"Alesis Digital Audio Tape"
<whitequark>
"Alesis Digital Audio Tape Lightpipe".
<whitequark>
this is some horseless carriage shit right here
<marcan>
it's just a less stupid encoding than S/PDIF, to push 8 channels over the same hardware
<whitequark>
oh sure
<whitequark>
i'm just boggling at the name
<marcan>
yeah heh
<whitequark>
uh. 12288 mbit baseband
<whitequark>
er
<marcan>
it's actually the most common studio digital interconnect for >2 channels, I think
<whitequark>
12.288
<marcan>
well recently people are finally selling things that just use ethernet or some actual glass fiber stuff and do shitloads of channels
<whitequark>
how do you want to generate that, PLL?
<marcan>
the data rate is actually variable
<marcan>
depends on the sample rate
<whitequark>
ah
<marcan>
that's 44100 * 256
<marcan>
I'm actually interested in 48000
<marcan>
but either way for the I²S to ADAT mode, it's just multiplying the source clock by some power of two
<marcan>
for an ADAT output applet, sure, PLL
<whitequark>
how do you want to multiply I2S clock?
<marcan>
good question. what's the PLL input range?
<whitequark>
way above 1.1 Mbps
<whitequark>
12 MHz minimum iirc? might be 16
<whitequark>
you'll need a DPLL for this i think
<marcan>
there is usually a master clock thing for I²S I think
<marcan>
but yeah I might need to implement something in logic
<marcan>
"Master clock (typically 256 x LRCLK)"
<marcan>
might not even need a PLL
<marcan>
just use that as is
<marcan>
but I need to check what MCLK is on my intended application
<whitequark>
ah
<marcan>
that's 12.2MHz btw
<whitequark>
yeah, the PLL can lock onto that
<whitequark>
in theory
<whitequark>
i mean, it can definitely lock onto that
<marcan>
tl;dr I want ADAT output for my keyboard, which has 6ch analog output but only 2ch spdif
<whitequark>
but using PLL is a bit annoying
<whitequark>
makes sense.
<whitequark>
keep in mind revB has 30 MHz system cloc
<marcan>
that shouldn't matter for a standalone application
<marcan>
and for dumping data to the host that's just a fifo
<whitequark>
sure
<marcan>
I'm going to be building this as a standalone board, I just figured revB would be as good a test board as any
<whitequark>
ahh
<marcan>
(as far as I can tell there is *one* ADAT encoder chip out there you can actually buy, it runs at 5V, and it doesn't support normal I²S, just several similar but not identical serial audio variants, and it's expensive)
<marcan>
so I'd need at least some 74xx logic to level shift and use that and basically fuck that
<gruetzkopf>
hm, i even have computers with native ADAT Lightpipe IO to try it on
<marcan>
I'd rather use a CPLD/FPGA
<marcan>
hah
<marcan>
I have a Behringer ADAT 8chx8ch interface and it uses *that* chip
<whitequark>
lol
<marcan>
and then I have a Focusrite Firewire audio interface (that's my main one) and that one has native ADAT in its bigass main soc
<gruetzkopf>
like - as long as you have a variant that has more than just two serial ports and ethernet you get lightpipe (and SPDIF-on-coax) if you want it or not
<gruetzkopf>
(it also has four PS2 ports!)
<whitequark>
four what ports.
<whitequark>
SPDIF-on-coax.
<whitequark>
what
<whitequark>
what cured hell is this
<marcan>
spdif on coax is normal?
<marcan>
like toslink is over the plastic fiber thing
<marcan>
and spdif is normally over coax
<marcan>
(same exact data, just different media)
<gruetzkopf>
PS/2, sorry, two sets of mouse+keyboard
<gruetzkopf>
and then there's the european broadcast unions take on SPDIF named AES3, which uses the same framing and sample formats, but it uses the non-audio bits in a different way.
<marcan>
whitequark: incidentally if you have any suggestions for the production fpga/cpld I'm all ears. the requirements are rather trivial tbh, especially if I can get away without using a PLL. it's just some stupid bitpacking: https://ackspace.nl/w/images/7/70/Adat_protocol.gif
<marcan>
(plus NRZI)
<whitequark>
marcan: isn't it like package-limited
<marcan>
I'd default to ice40something just because fuck vendor tools
<marcan>
package-limited?
<whitequark>
well do you want a bga or qfn or qfp
<marcan>
definitely not bga
<whitequark>
basically any fpga can do this
<marcan>
yes
<marcan>
and many CPLDs
<whitequark>
ice40hx1k then
<marcan>
those have NVCM?
<whitequark>
i think all of them have OTP NVCM
<whitequark>
or more like... 2-3 times programmable
<marcan>
oh really
<marcan>
how does that work?
<marcan>
append?
<whitequark>
no idea
<whitequark>
iirc tnt tested it?
<gruetzkopf>
really terrible EEPROM process?
<whitequark>
yeah my assumption
<marcan>
how does that happen?
<marcan>
I thought "OTP" was usually either EPROM (sans window) or fuses
<marcan>
how do you manage to make it an EEPROM, but a really bad one?
<gruetzkopf>
"bit 7: This "sampling frequency scaling flag", if set, indicates that the sample rate is multiplied by 1/1.001 to match NTSC video frame rates."AAAAAAA
<marcan>
you know a chip manufacturer is awesome when you can only buy their stuff from ebay and audiophile/instrument parts stores
<tnt>
whitequark: I didn't test it no. I just relayed the info from an earlier discussion in #openfpga. I don't think anyone has even documented the NVCM programming protocol yet.
<marcan>
whitequark: ice40lp384 if I can get away without the pll, otherwise lp1k? seems smaller
<marcan>
oh derp, no pll on the <144 qfps?
<marcan>
hope I don't need a pll then, otherwise hx1k is the smallest I guess
<marcan>
but that would be a massive waste of IO
<marcan>
I need... like 9 inputs and 1 output, being generous
<tnt>
marcan: did you look at what they call 84 qfn is ... not that qfn.
<tnt>
"dual row QFN"
<marcan>
aaaaaaaaaa
<marcan>
well I can't use that one anyway
<marcan>
I was thinking qfn32
<whitequark>
marcan: ultraplus then
<whitequark>
sg48
<tnt>
I pretty much limit myself to lp384 and up5k just because it's qfn32 and qfn48
<marcan>
those are creeping up on the coolaudio chip's price lol
<marcan>
I bet I can find a clock I can use on that board though
<marcan>
and avoid the PLL
<marcan>
(I *might* sell a very small run of this, there's probably <O(20) people in the world who want this)
<marcan>
(considering the device I'm building this for seems to be produced in O(10000) quantities)