Usb problems with Fun Cube Dongle Pro + #608
Comments
popcornmix
changed the title
|
Getting timeouts to multiple devices is a telltale that your device is attached to a single-TT hub. Please post a full |
|
I have now tried the FCD plugged directly into the PI and it works much better, but still gettting a few messages like this Looks like I need to get a better hub ! Is there a list of "good hubs" that won't give this problem ? EDIT: Not seen any more of those messages, and it looks like they come from the hid control interface rather than the usb-audio device. |
|
I would say that unbinding the HID endpoint would help, but from the frequency control source code it appears that it's used for controlling the device. Hubs are a bit of a crapshoot - USB2.0 hubs are now costed down to the point where chip manufacturers have even resorted to aggregating two 4-port hub dies in a single package (single TT of course). If you find one advertised as multi-TT then you have some recourse should it not be up to scratch. The only hub that I've seen that advertises this is the PiHUB - http://shop.pimoroni.com/products/pihub Please post a |
|
Yes the HID endpoint is used to control the frequency and other things in the RF sections. I know the FCD developer so I can pass on any comments you may have. |
|
Given that this is a SDR frontend bolted onto an isochronous streaming endpoint, does any data come out of the second audio channel? I.e. is the sampled stream mono or stereo? |
|
When I opened it as an alsa device it is stereo providing I/Q signals at 192kHz and 16bit resolution. |
|
Isochronous is a transport that should be used for guaranteed-bandwidth, periodic data (usually audio/video, but I/Q samples also fit the description). The Pi, for various reasons, has trouble with Isochronous full-speed devices that go above ~752 bytes per frame. One thing that could improve matters would be the addition of alternate settings - usually, several different alternate settings for the interface are specified to allow "optimal" allocation of bandwidth. As this is a custom device, there need not be any rigid adherence to the sample rate or bit depth commonly used in audio devices. Addition of an 8-bit mode or lower-rate sampling would take the data rate down below the bandwidth threshold for running out of frame time. |
|
Howard said "in the firmware source I have an option to be able to select all manner of rates and bit depths. Unfortunately windaz doesn't allow end-user selection and auto-selects bit depth over sample rate (max 192/16bit or 96/32bit on USB full) so I removed the option from the firmware,to simplify it for the 99%" So if other settings could give better results on the PI it might be possible to get a version of the firmware built with them included (though Howard may not want the hassle of supporting more than one build). I'm in the middle of refactoring my code so I've not had chance to do a "soak test" with the FCD plugged directly into the PI. I'll do that as soon as I have working code again. |
|
Latest discovery.... With FCD plugged directly into the RPI, ethernet activity sometimes |
|
Assuming that the interrupt OUT endpoint is only used when changing settings, I think you only have 125uS of leeway for scheduling latency (actually more like 90, due to various hardware constraints). Hubs will disconnect devices that "babble" over a frame boundary, which is a Bad Thing (tm), therefore the FIQ will not progress a transfer if it was asked to start it too late in a frame. With a 792-byte isochronous endpoint and a 64-byte interrupt endpoint, the transaction sequence will only succeed if the first transaction goes out right at the start of the USB frame. Delaying this sequence (due to interrupt latency) will cause timeouts. The sequencing is nondeterministic: either endpoint could get timed out. You're at the edge of what's supportable on the Pi's OTG. |
|
I've gone back to using a usb soundcard that samples at 96kHz, and with that plugged directly into the RPI I'm seeing these messages... Jun 1 17:41:43 pi1 kernel: [36563.917293] retire_capture_urb: 2 callbacks suppressed Do you know what causes these ? |
|
Just a thought, I'm currently not overclocking anything. If this is "at the edge" Is there anything that can be done in that area that will help ? |
|
Just had to try the overclocking this morning... With the settings below ("modest" plus a bit of a core boost) things are improved, though it still won't run for much over a minute without the FCD gettting somehow upset and requiring to be replugged. #uncomment to overclock the arm. 700 MHz is the default. gpu_mem=128 |
|
retire_capture_urb() is the callback function for the audio record USB request block, usually about 8 or 16 frames' worth of data. Each frame has a status field that reports if it succeeded or not: if nonzero then that means something went wrong. It appears that the usb sound driver continues with it anyway as long as there's a nonzero length. Amusingly, if the ratelimit is hit then the relevant messages don't get printed at all. It's odd that the dwc driver is a bit quiet when that happens: in theory, those transfers should be completely reliable barring bus errors. Overclocking will help somewhat, but the relationship won't be linear. |
|
Experiments this evening show it to be most stable when running with a hub with just the FCD plugged into it. It has run for as long as 10 minutes without anything being put into /var/log/messages. After 10 mins the FCD disconnected and reconnected (which killed my program of course). It's ho so close to working reliably at 192kHz sampling. |
|
Today I received a Pimoroni PiHUB which is a multi-TT design. Using this the FCDPP is working much better. It still occasionally disconnects and some messages are generated when the HID interface is used to set the frequency. The longest I've seen it run for is 16 minutes. This is with no overclocking in use so I'm now going to try some moderate settings and see if that helps. |
sudo lsusb -v |
|
There's a possible workaround for the HID endpoint at least: The BSD devs have found that you can cheat the hub by forcing interrupt transfers into the control/bulk handler. This removes many of the limitations found when dealing with periodic packets. It is a blatant USB specification violation but if it works then it'll free up a lot of low-speed bus bandwidth. This may push the 192kHz case into the "more useable" camp. |
|
The latest commit to https://github.com/P33M/linux/tree/fiq_fsm may make 192kHz capture more useable. It's a 3.10 branch but that shouldn't break anything. If you want to test it in advance of a firmware release, you will have to cross-compile and copy the image + kernel modules across to the Pi. To use the hack add |
|
On Fri, 2014-06-20 at 10:26 -0700, P33M wrote:
I'm not set up to do that, and 96 kHz is more than adequate for my PeterO
|
|
192kHz (Fs/2 = 96kHz) would allow sufficient capture bandwidth for software demod of FM + stereo + RDS :] |
|
On Fri, 2014-06-20 at 10:45 -0700, P33M wrote:
Not much of that on HF though ! PeterO
|
Ezequiel Garcia says: ==================== net: phy: Prevent an MDIO bus from being unloaded while in use Changes from v1: * Dropped the unneeded module_put() on phy_attach_direct(). The motivation of this small series is to fix the current lack of relationship between an ethernet driver and the MDIO bus behind the PHY device. In such cases, we would find no visible link between the drivers: $ lsmod Module Size Used by Not tainted mvmdio 2941 0 mvneta 22069 0 Which means nothing prevents the MDIO driver from being removed: $ modprobe -r mvmdio # Unable to handle kernel NULL pointer dereference at virtual address 00000060 pgd = c0004000 [00000060] *pgd=00000000 Internal error: Oops: 17 [#1] SMP ARM Modules linked in: mvneta [last unloaded: mvmdio] CPU: 0 PID: 22 Comm: kworker/0:1 Not tainted 3.16.0-rc5-01127-g62c0816-dirty #608 Workqueue: events_power_efficient phy_state_machine task: df5ec840 ti: df67a000 task.ti: df67a000 PC is at phy_state_machine+0x1c/0x468 LR is at phy_state_machine+0x18/0x468 [snip] This patchset fixes this problem by adding a pair of module_{get,put}, so the module reference count is increased when the PHY device is attached and is decreased when the PHY is detached. Tested with mvneta and mv643xx_eth drivers, which depend on the mvmdio driver to handle MDIO. This series applies on both net and net-next branches. ==================== Signed-off-by: David S. Miller <[email protected]>
|
I seem to get much better performance with the following: here is the post I got the information from: |
|
fiq_split_enable has no effect in latest firmware. LPM_enable is 0 by default, fiq_enable is 1 by default, fiq_fsm_enable is 1 by default. The only parameter that has any reasonable effect on the situation is fiq_fsm_mask. When you say "Much better", how reliable is the operation? |
|
I'm still getting this on a Rpi2, anything that can be tweaked?, as the Pi 2 should have enough power to run without issue. Transfer to device 4 endpoint 0x2 frame 1664 failed - FIQ reported NYET |
|
I'm not following the scene so much anymore but I have a feeling even in On 6 July 2015 at 20:05, Jester [email protected] wrote:
|
|
I was hoping for USB stack improvement, basically I want to use the FCDPP with a rpi2 as a remote receiver, and use virtualhere to forward the usb to my client pc, another solution is also welcome but I dont see it yet.... |
|
@PeterOGB has this issue been resolved? If yes, then please close this issue. |
|
Closing USB issues as OP has not updated the thread. Further comments by the OP stating that the issue is still present on latest rpi-update kernel will lead to a review. |
rust: file: Add `FileFlags` type for `File` flags
Latest firmware has fixed USB so that external usb sound cards will word at 96kHz. But the Fun Cube Dongle uses 192kHz, and when using it the following messages appear in /var/log/messages before the device is eventually disconnected....
The text was updated successfully, but these errors were encountered: