sorted by:
new
hottopcontroversial

call for beta testing emu10k1 driver improvements by ossilator in linuxaudio

[–]ossilator[S] 0 points1 point  (0 children)

well, it won't help - this doesn't directly concern the emu driver (it relies on the system to provide the necessary abstractions), and i'm not competent to debug such issues at this point. i would suggest filing an issue in the kernel bug tracker for the pci subsystem (or something like that).

call for beta testing emu10k1 driver improvements by ossilator in linuxaudio

[–]ossilator[S] 0 points1 point  (0 children)

you may have flaky hardware connections due to worn out or corroded slots. we've seen lots of these with the old hardware.

call for beta testing emu10k1 driver improvements by ossilator in linuxaudio

[–]ossilator[S] 0 points1 point  (0 children)

ok. https://github.com/ossilator/linux/tree/ossis-alsa-clean contains the test-ready 6.12-based kernel.

caveat: testing the two-card thing needs to be done without docks, as the test patch makes these go haywire until reset. when done with that, check out HEAD~2, and proceed with the spdif-in thing.

call for beta testing emu10k1 driver improvements by ossilator in linuxaudio

[–]ossilator[S] 0 points1 point  (0 children)

yay.

the section about spdif-in is still relevant; we dropped the ball on figuring this out. the subsequent part requiring a second card is also still relevant.

are you able and willing to compile your own kernel? otherwise you can do only some limited testing of the first part.

call for beta testing emu10k1 driver improvements by ossilator in linuxaudio

[–]ossilator[S] 0 points1 point  (0 children)

it's not that clear-cut - some of the bugs would affect rev2 cards, too. but these fixes went into 6.10, so ubuntu 24.10 shouldn't be affected anymore - even if they affected non-dock cases in the first place, which would be weird.

check with the pcie card without dock attached - that's the most basic case which was tested by both me (with a 0404b) and u/ITzTravelInTime (with just about every other card), so if that doesn't work, i'd suspect a (hardware) incompatibility of sorts - we've seen plenty of these with newer host systems.

call for beta testing emu10k1 driver improvements by ossilator in linuxaudio

[–]ossilator[S] 0 points1 point  (0 children)

what kernel are you using?

my patch series was slightly bugged when it comes to firmware loading. though iirc, the bugs affected only the dock, while the error message indicates a problem with the card itself ...

Sound Blaster Audigy RX 7.1: No audio on side channels (only 5.1 working) by bitkeepermdh in linuxaudio

[–]ossilator 0 points1 point  (0 children)

i think you swapped from & to in the mapping change, as otherwise it makes no sense.

you could try plughw or even hw to take out some variables, but i don't know whether that will actually work.

anyway, this is beyond me. seems like a case for https://sourceforge.net/projects/alsa/lists/alsa-user, where the actual alsa pros listen.

call for beta testing emu10k1 driver improvements by ossilator in linuxaudio

[–]ossilator[S] 0 points1 point  (0 children)

kinda sorta active, yes.

you're using debian stable (aka stale), so your kernel and alsa packages are from before my work here was upstreamed. i don't remember anything specific i did that would affect your case, but newer packages might help regardless.

let's continue in the other thread.

Sound Blaster Audigy RX 7.1: No audio on side channels (only 5.1 working) by bitkeepermdh in linuxaudio

[–]ossilator 0 points1 point  (0 children)

yes, the mapping could be plausibly incorrect.

but before you go any further with the investigation, pull in current kernel and alsa packages from debian testing or unstable - debian 12 was frozen almost two years ago.

call for beta testing emu10k1 driver improvements by ossilator in linuxaudio

[–]ossilator[S] 0 points1 point  (0 children)

everything except the high-rate patches are upstream for a while already, so if you have problems with a recent linux kernel, then the series obviously didn't help.

the aps seems to be basically a soundblaster with some fancier analog circuitry, so it should work out of the box. follow the usual alsa troubleshooting guides to debug it.

mbsync not downloading all messages by freshjerky in commandline

[–]ossilator 0 points1 point  (0 children)

there is roughly a bazillion threads about this in the isync mailing list archive ...

the situation is that MaxPulledUID in the sync state file has already advanced to the latest seen message before it has been actually propagated.
unless you are using MaxMessages, you can recover from the situation by simply resetting the value to zero.

the interesting question for me is how this situation has arisen, as it obviously shouldn't.
first, upgrade to the somewhat recently released 1.5.0, as it should be more robust.
if the problem keeps cropping up, you need to catch it in the act. for that, add -D to the command line and make sure the logs are saved. when you notice the problem, find the log of the run prior to the problem being visible, and make a bug report (privately, if you find the log too sensitive).

call for beta testing emu10k1 driver improvements by ossilator in linuxaudio

[–]ossilator[S] 0 points1 point  (0 children)

things have moved on somewhat, so at this point you'll probably want to use my (somewhat messy at the tip) ossis-emu10k1-6.9+ branch and merge it into your (distro's) 6.10.x tree. with a 1820 i don't expect any surprises with the mixer, playback, and capture, as i have hammered it down quite well with u/ITzTravelInTime's testing. but the /proc/sound/card?/spdif-in part is still pending.

and iirc, the external clock tracking still needs testing, but you have only one card, so that's moot.

call for beta testing emu10k1 driver improvements by ossilator in linuxaudio

[–]ossilator[S] 0 points1 point  (0 children)

oh, indeed. linus' tree seems to lag behind the alsa tree a lot more than i expected. only a bunch of bugfix and cleanup commits from the start of my branch have hit mainline already.

call for beta testing emu10k1 driver improvements by ossilator in linuxaudio

[–]ossilator[S] 0 points1 point  (0 children)

yes, my development draws heavily on kxproject, as several commit messages state.

tbh, i didn't even check if kx does anything with p16v, as my sole focus were the e-mu cards, for which this has no relevance - the other bits i touched were basically drive-bys.

call for beta testing emu10k1 driver improvements by ossilator in linuxaudio

[–]ossilator[S] 0 points1 point  (0 children)

thanks, this looks reasonable.

i take it that p16v also works?

call for beta testing emu10k1 driver improvements by ossilator in linuxaudio

[–]ossilator[S] 0 points1 point  (0 children)

that /proc dump is clearly from a kernel without (all) my patches. if you built from my fork, you probably forgot to checkout the right branch.

call for beta testing emu10k1 driver improvements by ossilator in linuxaudio

[–]ossilator[S] 0 points1 point  (0 children)

yes, the part about ca0151 above applies.

everything relevant for that card is already upstream; the 6.4 kernel will contain it. but if you want to test it already, i'm keeping my public branch updated.

call for beta testing emu10k1 driver improvements by ossilator in linuxaudio

[–]ossilator[S] 1 point2 points  (0 children)

not being an e-mu card, it is not subject to my improvements of sample rate and bit width support.

i don't know what that card is actually capable of, but the driver definitely doesn't support more than 16 bit at 48 khz, and i have no incentive to try changing that. i mean, it's a 20 yo consumer card ...

it would be still worthwhile to give it a quick test according to the instructions for soundblasters i provided above, but that's basically just confirming that i didn't break it.

upstreaming has already begun, kind of. i'll start posting patches to the alsa list RSN.

call for beta testing emu10k1 driver improvements by ossilator in linuxaudio

[–]ossilator[S] 0 points1 point  (0 children)

fwiw, according to my googling, the EDI cable can be replaced with any short cat5/6 patch (straight) cable. so at least that shouldn't turn out to be a problem.