Was it no feedback packets or feedback packets with zeros? Slow would mean below nominal rate (i.e. fewer than 48 frames every 1ms packet). I have never seen that, it would make no sense. The initial rate is nominal and the feedback packets tweak the momentary rate from the nominal one. If no packets arrive, no tweaking.
I do not see how windows could run faster than linux on the same hardware if both output nominal rate and why they would not output nominal rate if no feedback was available...
Also how it would happen that windows fits the device rate almost exactly to run OK for hours, especially with the short device buffers..
Also how it would happen that windows fits the device rate almost exactly to run OK for hours, especially with the short device buffers..
I vaguely recall some xhci controller had a register for slight tweaking the PLL to generate the internal clock. Theoretically windows could have set this register differently than linux, resulting in faster USB speed.But that's wildly guessing, I looked at that very long time ago.
No harm intended @bohrok2610, only folks trying to wrap their head around what you saw.
Such XHCI clock tuning would resemble virtual software clock tuning. I don’t know enough about USB to know whether a host will allow a peripheral to slow it down, or buffering would be the only band-aid.
Such XHCI clock tuning would resemble virtual software clock tuning. I don’t know enough about USB to know whether a host will allow a peripheral to slow it down, or buffering would be the only band-aid.
Look at Frame Length Adjustment (FLADJ) - page 12 of https://www.mindshare.com/files/resources/mindshare_ehci_whitepaper.pdf , table 5-6 page 375 of https://www.intel.com/content/dam/w...ensible-host-controler-interface-usb-xhci.pdf . IIUC that register allows tweaking SOF length enumerated by 480MHz cycles (60k ticks => 125us). I could not find any access to register 0x61 in linux kernel in uhci/xhci/ehci, this register is not defined in headers and is not listed in debugfs. IMO linux does not touch this reg, therefore the default value of 0x20 (= 60k ticks) should be preserved. I read somewhere that bios could be setting this too. Theoretically windows could be setting the default 0x20, while linux could preserve some non-default value set by the bios, many ways, all quite unlikely...
Does anyone know if this solution still works these days?
http://pavouk.org/hw/audiosystem20/en_at32uc3a3256usbi2s.html
http://pavouk.org/hw/audiosystem20/en_at32uc3a3256usbi2s.html
I rechecked this with Wireshark. Turned out there was something fishy happening at enumeration. This was caused by PulseAudio which wanted to use my device as default sink and source. After disabling PulseAudio the issue seems to be gone. Now both Linux and Windows act the same. Depending on the clocks both can run for tens of minutes (maybe hours) with no async feedback without causing buffer over/underruns in my device.
I only use Linux (Ubuntu) occasionally for testing but IMO the audio system is somewhat messy. This may also be due to Ubuntu distro.
MAX14930CASE (or FASE) should work and has much lower jitter. But like miro1360 said one option is not to use an isolator.
IMHO PA just tried opening your device in various samplerates, that the driver reported your device supports. It opens a device shortly at startup. It's one of the reasons I implemented debouncing in https://github.com/pavhofman/gaudio_ctl#debouncing
PA has no special access to alsa devices, it uses standard alsa-lib like any other audio app.
PA has no special access to alsa devices, it uses standard alsa-lib like any other audio app.
Well then you are lucky your PC and STM clocks fit perfectly. In my tests of RTX6001 without enabled implicit feedback in the linux driver the XMOS buffer glitched every 10 secs, a different combination did so every several minutes. Pure coincidence, IMO.
Yes, that is what happened according to Wireshark. Apparently something went astray as my device has also non-standard samplerates in the list.
Yes, pure coincidence. But assuming async feedback is not working those recurring glitches may explain why some people complain about noise with USB-I2S boards.
Hm, probably not worth investigating more. But I do not think linux would be somehow feeding your device a different samplerate than set to your clock feature because the buffer issue in your device would occur much faster than in minutes.
No, I don't have the time (or expertise) to study the innerworkings of PulseAudio or Linux. Actually enumeration failed quite frequently as PulseAudio kept playing at some samplerate.
Of course the async feedback must work properly to avoid the buffer issues. That would suggest there is an issue in the USB-I2S firmware.
Hm, what do you mean by failed enumeration? PA supports only standard rates and it runs in a pre-configured rate, like windows audio subsystem. If your device does not support that rate, PA fails to use the device. But I do not see any way how the host could feed your device with a stream just slightly higher/lower than the pace expected by your device at the given samplerate. It would maybe hint at some issue in your firmware like it would not handle the short playback properly, not resetting some variables for new non-zero altsetting, something like that, I do not know.