On my E-MU 8810 PCI sound card (snd_emu10k1 driver) with the E-MU 8810 dock, from kernels >=6.6, it stopped initializing. Using a kernel compiled from source, I have been able to narrow down the issue to commit fbb64eedf5a3a98071ee75808cfc1367d1e75783 that changes the fpga initialization method for all EDSP cards. I can confirm to you that reverting that commit got rid of the issue entirely and made my sound card usable again. It seems to me that the older DSP chip used by the 8810 lacks (or at least has some differences compared to later DSPs, with) the interrupt feature for the interrupt-triggered initialization introduced in that commit. I have also done tests with more recent EDSP cards using the same driver, specifically, my E-MU EM8986 and my E-MU ESDP CardBus, both with the same 1616m dock. Both do initialize on kernels >=6.6 while having the dock connected at system startup, however the dock does not seem not initialize after hot plugging it (unlike earlier kernels), at least to my tests. So it seems to me that this interrupt-driven approach is pretty flawed, and might be a good idea to revert to the old one-second polling timer method, even though it might use some very slightly more system resources.
Errata: In the first comment line I wrote "E-MU 8810 dock", what I meant is "E-MU 1820 dock".
Oswald, this looks like a regression by your change. Please take a look.
wow, we finally seem to have found that one person in the world who still uses these things. with linux. and has multiple of them! 😂 so while you're here, let me invite you to https://www.reddit.com/r/linuxaudio/comments/11i7qf6/call_for_beta_testing_emu10k1_driver_improvements/ a bit belatedly. the authoritative branch for users is now https://github.com/ossilator/linux/tree/ossis-emu10k1 ; https://www.alsa-project.org/wiki/Matrix:Module-emu10k1#Downstream_Patch contains some details, too. anyway, back to topic. i'm not surprised that this is broken, given what i had to work with. sorry for the inconvenience. i'll cook up a patch shortly, to test whether there is only some minor implementation problem, or my idea about how dock interrupts work is fundamentally flawed.
Created attachment 305980 [details] fix cold-plugging i was initially a bit surprised that cold-plugging doesn't work with 8810, as in that case we are still polling. however, it occurred to me that on these cards the dock is powered by the card, which is turned on microseconds before we query the dock. so the dock doesn't have enough time to boot before we query it, and we subsequently rely on the dysfunctional hot-plugging path. the delay is pulled out of thin air - it could be 50 or 2000. please try to figure out the lowest value that works reliably for you, and i'll use twice that for the final version. actually, maybe even more than that, because you likely have quite dried out capacitors which charge a lot faster than they should (these audio-docks pretty much always die of bad caps due to running a bit too hot). this patch won't be necessary when hot-plugging is fixed, but i think it makes some sense regardless. maybe without the delay in the end, but with a more verbose comment instead.
Created attachment 305981 [details] test hot-plugging this should help us figure out what is (not) going on. please test hot-plugging and hot-unplugging after cold-plugging (with the other patch applied and confirmed working), with all cards you have, and post the related messages from the end of dmesg after each attempt. this patch may also help debug sync loss detection, if you feel like testing it per the reddit post.
Hi thanks for the reply, i will test the changes and report here as soon as i can. It might take a while for me to test them on the edsp cardbus though, since i don't have it permanently deployed in some pc. Since i also own many consumer grade cards supported by the emu10k1 driver i might also test the code there too, of which i have 3 such cards (audigy rx, e-mu EM8986 and audigy 2 zs) in my proxmox/arch linux dual boot machine permanently deployed. If you wonder why i own those cards it's because i am a contributor to the kx audio driver project and did some work to it, including back porting the mac side to ppc architecture for use on some of my 2000's macs. I will let keep you updated regarding the patches, thanks.
Update on the 8810 + 1820 dock patch: with a delay of at least 1 second I got the dock powered on but no dock initialization, all lights are on after boot, so all registers must be set to a default value. Same behavior with pretty much up to 10 seconds which is the maximum i have tried. I also tried hot plugging it after boot and the dock powers on, but still no initialization. I think the old pooling timer method works because it tries to program the fpga over and over again, therefor not depending on exact delays, we can perhaps simulate that for about 20 or 30 seconds using a for loop after the dock has been detected, or you might also take a look at how the fpga programming is being handled by the kx audio driver's edspctl program, since it's all done in one go, so you can implement a similar logic triggered by the dock detection. About the other possible patch for hot plugging the more modern cards I have not been able to test it yet, for now my priority is my 8810 + 1820 dock which is completely unusable. That's it for now, thanks for the help!
if your hypothesis that retrying helps is correct, then the problem is that the programming is unreliable, not anything with the detection or delays. regarding the kx driver, the 1010 variant's Hal::upload_fpga_firmware() is so similar to our snd_emu1010_load_firmware_entry() that i'll just presume that one of them is a copy of the other, or that both are very accurately copied from the windows driver. one obvious difference is that the kx driver does not include my patch a1c87c0b27 (ALSA: emu10k1: fix access to Audigy GPIO port), so the timing may be subtly different. anyway, rather than guessing, we should actually see your dmesg. neither of my patches will actually fix hot-plugging; it's also all about the dmesg.
Indeed, the dmesg, let's see what the data tells us, I am going to do a test using a 20 seconds delay value, and then I will post the dmesg. About the logic by the kx audio driver I was referring to the higher level logic that handles fpga programming in the edspctl program, because it conditionally re-attempts fpga initialization as I have seen, that might be a better way of handling it if the re-trying option is correct, rather than using a loop for 30 secs or so. But I must say I am unfamiliar with how that's handled by the Linux driver. Anyway, I will email the dmesg as soon as I have it. Thanks. PS: Sorry if I mistook the hot plug modification for a patch.
Here is the dmesg http://0x0.st/HFLz.txt and a journal for good measure http://0x0.st/HFLr.txt It all seems normal, but the dock has still all lights on and no sound.
there is no need for posting the full journal (and dmesg is basically just journalctl -k). the log says "Card options = 0x0" (so no dock) but subsequently the firmware is loaded, with no messages in between. so you're apparently running with your revert, rather than with my patches? but then it should work, so i'm confused. please remember to post logs from hot-plugging experiments, per instructions above.
That's wired because i thought i got rid of that revert in my local mainline clone, well i will do a fresh clone of the mainline kernel and apply the changes to it, then post the dmesg. If you prefer me to use your fork just tell me which branch. Sorry if things are slow btw, we might arrange a chat or something to go back and forward more quickly when my job allows time for it. So let me know. Have a good day.
recloning seems a tad radical. just examine your local git history. if the revert is there, rebase it out. using my clone isn't required at this point. i'm ossi on libera.chat and @ossi:kde.org on matrix. european time zone.
So after lots of tests and back and forward between me and Oswald the issue has been fixed and patches have been submitted (without requiring any reverts, the new interrupt-driven method was instead improved upon), so I mark this Bugzilla issue as resolved. We are also working on doing some more tests and regression checks to make sure things work as they should, and so Oswald might send more patches if needed. Thanks everyone for the help, especially Oswald. Have a nice day.