<ktemkin>
I’m just about to pass out for the night, so I probably won’t have enough brain to do Reasoned Thought about that until the morning
<ktemkin>
at least, not without risking finding myself in a three-hour "you know, I wonder what the HCI will do if I <...>"
<whitequark>
hahah, understandable
<ktemkin>
but, out of curiosity, what environmental constraints do you have re: HCI/HCD?
<whitequark>
Linux, XHCI, this is a one-off project I do for myself
<whitequark>
tl;dr Bluetooth is criminally underpowered and if I go behind a fridge my headphones lose signal
<whitequark>
I want to dump all the garbage involved and just stream PCM using nRF24L
ec0 has joined #glasgow
<whitequark>
48k 2ch 16bit PCM just about is possible to transmit in 2 Mbps mode, and nRF24LE1 has just about enough power to stream it to some DAC, but LU1 can't actually receive it through USB
<ktemkin>
ah, okay; anything XHCI would mean that I'd have to actually think while looking at the spec
<whitequark>
(not that I want to use XHCI, but this laptop doesn't leave me any other options)
<whitequark>
actually, how on earth does linux enumerate full speed devices through XHCI?
<whitequark>
I thought USB 3 doesn't have TTs?
<whitequark>
and I've definitely seen laptops that require concurrently loaded ehci_hcd and xhci_hcd?
<ktemkin>
it doesn't have SS TTs, but that's because there's electrically independent SS and HS busses, so there's no equivalent to "slowing the bus down" to transfer lower-speed packets
<whitequark>
oh, so it has one HC interface that controls effectively two independent HCs?
<ktemkin>
AFAIK, the machines that have EHCI+XHCI for the same USB controller are using a bit of intel devilry that tries to maximize compatibility by presenting EHCI and XHCI interfaces to the same piece of hardware (typically on two different PCI functions on the same device), and then selectively presenting devices on controller or the other
<whitequark>
the machine where I've seen that didn't actually work if you e.g. blacklist the xhci driver
<whitequark>
no devices would enumerate, I never figured out why
<whitequark>
so it doesn't seem like that devilry worked lol
<whitequark>
(i.e. unless the XHCI driver was *loaded*, no device would enumerate on the *EHCI* controller, whichever version)
<ktemkin>
I don't remember the heuristic it used to decide there was a "legacy os" present and keep everything on the EHCI controller
<ktemkin>
I remember that you could write into one of the BARs used for configuration and effectively ask the controller to move devices between the two PCI functions
<whitequark>
what the hell
<whitequark>
devices that are currently plugged in?
<ktemkin>
er, it moved the 'port'; not the model-of-the-device itself
<ktemkin>
amusingly, when those first came out, you could actually have the VT-d IOMMU map the XHCI and ECHI functions into different DMAR domains, and thus e.g. map the two functions into different virtual machines
<ktemkin>
a while back, I experimented briefly with using it for high-performance USB passthrough
<ktemkin>
e.g. keep the XHCI function in your "host" domain and then use pci-passthrough to stick the EHCI function into your guest
<ktemkin>
it worked way better than it should have, except that the PCI device utterly lacked FLR, so you could only really re-initialize both controllers at once
<ktemkin>
(effectively just an optional extension to the PCI spec that let you reset a function without resetting the whole bus or device)
<whitequark>
yeah, makes sense
<whitequark>
I think these days you can't map individual functions, because of ACS?
<whitequark>
I never quite figured out if it was a kernel restriction or hardware one
<ktemkin>
I haven't read PCH specs since I stopped doing virtualization
<ktemkin>
something something "I _am_ a masochist; but reading intel chipset specs still is going a bit far"
<whitequark>
hey, I *did* read those for fun
<whitequark>
and i'm supposedly not even a masochist
<ktemkin>
I used to enjoy reading them, but they've become super associated with the toxic workplace where I did low-level intel stuff
<whitequark>
oh.
<whitequark>
that'd do it
<ktemkin>
so it has to be one of those things where I have to be nerd-sniped into a problem before I'll thumb through them, rather than just picking them up for morning-specification-reading
<ktemkin>
(spec-reading is often very much a "i am waking up and putting off actually starting my day" thing for me)
<whitequark>
oh mood
<ktemkin>
anyway, re: your original query, typically the hack to get an {O/E/X}HCI controller to spew out transactions in a way it doesn't like is to take advantage of the structures they use to maintain state
<ktemkin>
so on OHCI, for example, you might be able to do what you want by adding multiple endpoint descriptors to the endpoint queue that have the same endpoint number, and then giving them each a single transaction
<ktemkin>
(it'd be pretty trivial on OHCI, actually; the hard part would just be getting the send-on-frame numbers set up so you'd have the right PID ordering across a constant stream of transactions)
<whitequark>
I thought ISO doesn't use PID toggling?
<ktemkin>
er, yeah -- not on OHCI+FS; you're right
<ktemkin>
my brain keeps translating consecutive "sub-frames" into microframes
<ktemkin>
actually, if you `lsusb -t` on your laptop, is the topology flat? i.e. is there pretty much one port per bus?
<whitequark>
the laptop with XHCI/EHCI is long gone, like, almost a decade ago i think
<whitequark>
this one has:
<whitequark>
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
<whitequark>
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
<whitequark>
which makes sense I suppose
m4ssi has joined #glasgow
<ktemkin>
what I don't know about XHCI is how it handles generating split transactions for isoch out; since I haven't experimented with using its device context model to address LS/FS devices
<ktemkin>
I'm not sure _what_ happens if you provide an Interval in the endpoint context that's lower than is legal
<ktemkin>
you're supposed to set those >= 3 for FS isoch, skipping the values 0/1/2 as they refer to 1 microframe, 2 microframes, and 4 microframes
<ktemkin>
it's possible that setting those lower will generate additional SSPLIT -> OUT -> DATA transactions, which might get the transaction translator to do what you want
<ktemkin>
anything more than that is going to be both Very Cursed and unlikely to work, based on the cursory re-read of the relevant spec sections that I accidentally did
<whitequark>
ktemkin: thanks! that's exactly what is helpful
<ktemkin>
(Very Cursed would be things like establishing a secondary device context object on the same bus, which would roughly represent another device connected to a downstream hub, but setting the port+slot the same)
<whitequark>
I suspect I'll just have to use nRF52 in the end, or maybe using interrupt transfers
<whitequark>
(unless the USB device in nRF24LU1 could be misconfigured to accept ISO packets to bulk/interrupt endpoints or something)
<whitequark>
(or the USB audio driver in linux to do the inverse)
<whitequark>
(actually I could probably just patch the USB audio driver to make it accept interrupt endpoints, now that I think about it, which would be vastly easier than messing with XHCI registers)
<ktemkin>
I mean, you probably can spam that data over a bulk endpoint just fine
<whitequark>
oh certainly, it's more that I'll need an ISO feedback endpoint for this stuff to work, and also thread it through all the upper layers like alsa and pulseaudio
<whitequark>
since the receiver can't really implement a PLL in this scheme
<ktemkin>
~~have you considered just streaming your audio through your phone~~
<whitequark>
yes, actually
<whitequark>
I want to use wireless headphones for e.g. watching videos as well, and the latency hit is too large
<ktemkin>
I need IRC-markup for double strikethrough so I can write something like "have you considered watching videos on your phone"
<whitequark>
I wanted something like this for like 12 years at this point, nothing I've tried before was quite nice enough
<whitequark>
oh
<whitequark>
you know, an ideal solution would be just streaming the audio as an analog signal
<whitequark>
back when i was a teen and had no money, some of the usual suspects (itead?) carried a pair of modules that did FM or something, made as if exactly for this project
<whitequark>
and recently i looked again and it looks like there's no off-the-shelf solution, and i also suck at analog design, much less analog rf design, so... nrf24 it is
<whitequark>
it was fun pushing nrf24 to its limits
<whitequark>
i figured out that it's very likely their datasheet-listed duty cycle requirements are more like duty cycle recommendations, and you could carefully time the transmitter PLL enable signal to transmit as much as the physical PLL drift permits you
<whitequark>
it's a very nice little radio/SoC, and of course everything i discover still applies to nrf5 too
<ktemkin>
I've liked them in the past, when I've worked with them
<ktemkin>
I have a stack of various radio boards $work has designed that theoretically might even one day have firmware written for 'em
<whitequark>
so far i managed to add promisc mode to them (semi-independently from travis goodspeed) and glasgow now has monitor mode applet
<whitequark>
which lets you receive enhanced shockburst packets without the chip auto-replying to them
<ktemkin>
nice
<whitequark>
:3
<whitequark>
i wonder how wide is the PLL stability region and how far can i shift the carrier frequency by manipulating the crystal
<ktemkin>
ossmann and I wound up having very nearly that exact train of experimentation while trying to push a 2.4GHz-intended chip down to 1.9GHz for DECT
<whitequark>
did it work?
<ktemkin>
we got it down to 2.1GHz, but no further
<whitequark>
aw
<ktemkin>
and then moved on speculating about the internals of the chip until we'd pretty much figured it out, since it was an idle thing we were doing after lunch on a Friday
<ktemkin>
you could underclock the thing, and you'd get more and more frequency offset and attenuation; and then suddenly it'd jump back up in frequency
Exec1N has joined #glasgow
<ktemkin>
ostensibly as an overtone started falling into the little resonance valley
nicexe has quit [Ping timeout: 268 seconds]
<ktemkin>
at which point I figured out that there was a register that helped you to configure the filter's resonant point; and that seemed like it could help to skew the clock further; but then discovered that it'd been fused as R/O for Compliance (TM) on the model we could get
<ktemkin>
anyway, this doesn't seem to be sleep, so I'm going to try and course-correct >.>
ali-as has joined #glasgow
ExeciN has quit [Quit: so long king Bowser]
Exec1N has quit [Ping timeout: 265 seconds]
Exec1N has joined #glasgow
massi_ has joined #glasgow
m4ssi has quit [Ping timeout: 265 seconds]
Exec1N has quit [Ping timeout: 272 seconds]
massi_ has quit [Remote host closed the connection]
Exec1N has joined #glasgow
Stormwind_mobile has quit [Read error: Connection reset by peer]
Stormwind_mobile has joined #glasgow
Getorix has joined #glasgow
Exec1N has quit [Ping timeout: 268 seconds]
Getorix_ has quit [Ping timeout: 260 seconds]
Getorix_ has joined #glasgow
Getorix has quit [Ping timeout: 265 seconds]
disasm[m] has quit [*.net *.split]
disasm[m] has joined #glasgow
disasm[m] has quit [*.net *.split]
disasm[m] has joined #glasgow
electronic_eel has quit [Ping timeout: 268 seconds]
electronic_eel has joined #glasgow
<_whitenotifier-3>
[glasgow] electroniceel opened pull request #181: Add comments about IO-buffer enabling being only on revAB - https://git.io/JvGLV
electronic_eel has quit [Ping timeout: 265 seconds]
electronic_eel has joined #glasgow
<_whitenotifier-3>
[glasgow] whitequark closed pull request #181: Add comments about IO-buffer enabling being only on revAB - https://git.io/JvGLV
<_whitenotifier-3>
[GlasgowEmbedded/glasgow] whitequark pushed 2 commits to master [+0/-0/±5] https://git.io/JvGtY
<_whitenotifier-3>
[GlasgowEmbedded/glasgow] electroniceel 33db40d - firmware, device.hardware, applet.internal.selftest: add comments re nOE lines only existing on revAB
<_whitenotifier-3>
[GlasgowEmbedded/glasgow] electroniceel 606ff40 - firmware: rename PIND_OEQ_N to PIND_OEQ_N_REVAB
<electronic_eel>
whitequark: about your nrf24 audio bridge: your problem is the max tx duty cycle before the freq drifts too much, correct?