I have this strange hobby to fact-check all your comments, because i have strange hobbies.
What i did: i simply made a search with <cardname> lspci to find the PCIID and went to find any reference for it in the Haiku tree, as you stated:
So they must be referenced somewhere in the source tree, right? Sadly i was unable to find any, could you help to find them?
Also:
According my search the Xonar D1 based on CMI8788, but the CMI driver doesn’t contains this ID:
So i am a bit puzzled.
Do you have first-hand experience with the listed cards? Your comments hints this, but you know, devil is in the details, so yes or no? (<- this is a question, it would be nice to get an answer to it. I had to add it before we get a cryptic answer as always.)
Keep in mind, your list is always-changing, like the universe. Now do they work with Haiku in default, or will they just dissapear after you have seen this comment? Maybe your statemenet will morph into they should work with OSS, which not the same as telling work in default and not the same as stating Haiku supports them and also not the same as works with OSS.
You’re right. OSS is not part of the ‘default’ Haiku drivers that come in the OS distribution releases.
I was told by Haiku dev that OSS is used to support legacy sound chips/cards for Haiku versus most of the included OS sound drivers (outdated). Hence, my faulty inclusion of OSS as ‘default’ versus ‘supported by Haiku’ through Haiku’s ports collection.
CMedia CMI8788 (under OSS Linux page section, it shows ‘ASUS Xonar D1’ supported)
CA0106 (Audigy LS/SE)
Haiku’s own driver listing of the CMI 87xx chips. The existing Haiku bug report says the CMI driver is still faulty. OSS supports them.
Yes. I own Xonar D1/SE, Creative Sound Blaster Audigy/Audigy2/X-fi cards (I showed my picture of the X-fi external module in the forum 1-2 years ago). Most of my older sound cards have the MIDI/Joystick and S/PDIF output/input. Haiku is part of my home movie theater and other things.
No, I don’t have the Audigy SE. This was mentioned as supported under the OSS FreeBSD port - yet, when I looked closer at the Haiku OSS port - it wasn’t there as you mentioned (PCI ID).
I mainly was referring to the Audigy Fx as supported by Haiku (by default HDA driver) which is why I had originally deleted the Audigy SE card (i.e. default HDA driver versus third-party driver ‘supported’).
Thanks. The SB PCI 128, SB Live! 5.1 (CT4620), and SB Audigy Platinum (SB0090) verified working with Haiku.
Specifically, my original test card for Haiku was a 2001-2002 Audigy2 PCI w/EMU10K2 (CA0102-IAT) and 15-pin MIDI / Joystick port extension header. For fact checkers, it is the SB0240 card w/ ‘gold-plated’ ports (not the multi-colored ports).
If someone is not into fixing, updating, bug reporting, or developing drivers, just get what works with the Haiku’s HDA or OSS 4.x drivers.
So today i was able to continue my misery tour with the arrival of a SB 1570.
(Short read: I’m afraid that i will keep connected to macOS for a while, at least for audio.)
After some experiments with the bios and opensound i was able to boot my system and not end up with a kernel panic. I was able to play with lmms and clementine just “visually” – that means the corresponding level indicators and equalizers moved for the first time. However no signal at any output …
Interestingly, after my last start, the syslog_daemon and kernel_team processes are now spinning up like crazy, but only on the second processor core (which i didn’t have seen before)?
I’m going to send detailed bug reports of course, but after that I will wait a bit before buying a third or fourth sound card (I already did that for the most unsuitable audio platform on earth: linux.)
Yes I know, but (my) problem is the height – unfortunately I have a small form factor system.
Perhaps I should change the mainboard, not the sound cards
By the way, which model number do you exactly have? I’ve found different »Live« models.
ah ok sorry I understand height as high…
not sure than…
the sound card i use is Soundblaster Live! PCI (Chip EMU10K1-ECF) Model CT 4620
old card… all contacts golden…
Excuse me and please dont be mad at me, but i am the wrong house-number here, as i am not the one who recommended 2 cards as “supported”, while they are not.
If you re-read the thread, nobody said: “hey pick this, this low profile card will work”. Except you.
So @stoltenberg invested time and money for 2 cards because your input. I hope he can return the -otherwise- fully functional hw, but have you ever considered what if he can’t? What if the price of those cards considered as “high amount of money” in his country? And what about his time?
This also makes bad experience for the users, what we want to avoid.
I dont mean you should say sorry, because different house-different fashion (for example in my country in similar case it would be absolutely expected), but at least you should consider it.
And no, i dont really like to write this, i just cant tolerate baseless statements, which is unfortinately happens way too frequently with you.
And no, i am not a sheriff and I am not against you, i just have too less time to do something productive but too much to watch the walls around me.
I would feel very uncomfortable, beeing responsible for discord and misunderstandings. Thank you @cocobean for your tips and you @extrowerk for supporting me too.
I’m sorry if I looked too frustrated. Maybe I forget - as a spoiled mac user - for just a moment that this is an open source project,
in which many people invest a lot of time and the whole thing is much bigger than a stoltenberg and his wish to play a few tunes on his strange hardware.
The frustration is forgotten and I believe that I’m able to sell the two cards. They were not expensive.
At the next opportunity I’ll try again and maybe my/our little odysee will help some others …
As this statement was made, I’m known to verify things as well and found this logic as faulty. Depends on how the software is written for ‘generic’ versus ‘specific’ usages. Similar to how one says something is ‘compatible’ versus something is ‘compliant’. This saves a software engineer much time of having to update code for every hardware product release (i.e. within a certain family group/compatibility).
Technically, the SB1570 is a HDA-compatible product. If the HDA driver itself is compliant/compatible to the HDA spec, then an HDA-compatible/compliant card “should work” without much/or any effort from the basic and/or advanced user.
Even drivers with PCI IDs present don’t always work properly with
specific product releases, so the logic is faulty there as well. Just because the PCI ID is there, doesn’t mean all is well. Lots of examples and bug reports to factually back that comment.
