Personally, I have always found recompiling from source a satisfying and rewarding thing to do. Kudos!
(1) the issue may or may not have involved bit depth change.
In my case, once the OS had booted and I did an “lsusb”, I could see the DAC but when I started playback it would disconnect.
dmesg showed "EPROTO 71 / Protocol error /" as the reason
So it might have been a bit depth change issue. All my files are 16/44 so if the DAC connected at some other rate (internally its 24/96) then yes it would involve a bit depth change.
I will see if I can determine what bit rate my DAC defaults to on connection but I assume it is 24/96
(2) No, using a USB 2 hub didnt help.
Forcing an intermediate change to USB 2 via the hub still meant I was ultimately going through the xhci receiver on the motherboard, which as we will see below, was my issue.
(3) Does your PC hardware have a USB 2.0 port?
Yes, ultimately as discussed below.
What pushed me to a solution was I had an old desktop PC with only an ehci (aka USB 2) USB controller which worked fine but my new target PC (a small compact NUC like ASUS PC) only had xhci (aka USB 3) controllers and it didnt work.
So the issue was with the USB 3 stack (or its interaction with the XMOS receiver).
I also had in my stock of PC’s, some fanless, small form factor Gigabyte Brix PC’s that had both ehci and xhci controllers and using this command 'lspci -nn | grep USB | cut -d ‘[’ -f3 | cut -d ‘]’ -f1 | xargs -I@ setpci -H1 -d @ d0.l=0" was able to force all xhci connections over to ehci and all worked fine.
But my ultimate end game was for my end point to be a diskless client that booted into ramroot off a USB stick but when the running ramroot image had the above command run, it all turned to custard as the OS still needed to see the USB stick and the forced USB stack change knackered that.
So I needed to hack the kernel to get to my desired end state
(4) What does this involve? Changing config file(s)? Modifying a bunch of source code?
The change was ultimately easy enough.
There as no guidance from “Dr Google” so I just went into hacking mode. In the end I just needed to change some header files and some config files to force the kernel build to not include the xhci stack.
I obviously wasnt sure if, even after a clean compile, that Linux would boot and run ok, but it does.
(5) NOTE: VERY IMPORTANT.
My use case [where I wanted to boot ram root into a small form factor PC AND connect to my DAC via the XMOS receiver AND remove the offending compatibility issue between the XMOS receiver and the Linux USB 3 stack (proven to be the issue on two different PC’s, as noted above, with ehci only and ehci/xhci motherboard chips respectively)] only works because my now target Brix PC*** supports both ehci and xhci.
Running the hack on say an intel NUC with xhci only means you end up with no USB stack.
So all I was trying to point out in my orginal post (without all the nasty details) was that my issue (which might be bit depth related) has conclusively related to the USB 3 stack/XMOS receiver interface.
*** I have three of these so I have enough spares to keep my current setup valid until I change my DAC
Assuming this is still an issue for people, if you can provide me with a simple test case (rather than me having to read the whole thread) I am happy enough to come out of retirement and see if I can provide a solution that works with xhci controllers or whatever the root cause is (assuming it can be resolved from the Linux side)
Aside from the test case, what logs do you have?
For, example, what does dmesg show when the issue occurs, so I can ensure the test case I run produces the same error.
Does this forum support PM’ing people? If so and you want me to have a look, PM me so we can exchange email addresses.
My dev lab was/is in my house (connecting from Down Under into the US Mothership was too cumbersome), so I still have tons of hardware lying around, not only intel PC’s but also solaris/aix/hpux servers (not that they are related to this scenario).
Peter
PS. I have run Roon in the past, with LInux as the endpoint, so am familar with using Roon
Indeed, especially when it solves an issue standing between you and audio nirvana (whatever that is for each of us)!!!
Thanks for the write up and the offer to help. I’m not experiencing an XMOS issue, but since this is related to our work I try to learn more about it.
Hi all and @brian!
I know this is going back to a dead thread, but is there any hope for me using a Pro Ject S2 Pre Box Digital?
For what’s it’s worth, I only experience the static when switching between sample rates IF I have upsampling enabled. It doesn’t matter how I’m doing the upsampling; any option except “for compatibility only” will trigger it.
Thanks in advance.