EMU10K1

[musicman]

have been looking at the FreeBSD apps site. Unexpectedly, ran across this. The only thing I understand....besides the fact that I can't understand the programming too well for this...is that some of it is extremely unfamiliar.....and after what I saw today....some of it is very familiar...exact, in a couple of places or so, if I am not mistaken....

[Kevin McAleavey]

Dec 15, 2010 17:20:56 GMT -5 musicman said:

Sigh - apologies all around. I have worked on this several hours today. i just now reread everything, and realized that, on this computer at least [PESV], you already knew everything. I should have read the diagnostics code BEFORE the AC97 snippet you sent. Oh well. Enough for today.

And an apology back at ya ... it looks like the failure of that motherboard to mask the disabled internal sound device is causing code that *I* wrote to be causing the problem here. One of those "unexpected situations" for which all these beta tests exist. I owe you a debt of thanks for tickling the tiger here!

I'm going to finish over in your new thread since this is interesting indeed ... looks like I have to find some time once the IPSEC drama settles down to go and improve the original sound detect code to deal with "dead devices still sitting on the bus."

[Kevin McAleavey]

Dec 15, 2010 19:20:45 GMT -5 musicman said:

have been looking at the FreeBSD apps site. Unexpectedly, ran across this. The only thing I understand....besides the fact that I can't understand the programming too well for this...is that some of it is extremely unfamiliar.....and after what I saw today....some of it is very familiar...exact, in a couple of places or so, if I am not mistaken....

OK ... I'm a wee bit confused as to what you mean above ... care to shed some details?

[musicman]

yes - simply that:

there was a line message saying that the Creative Audigy card was detected, and listed EMU10k2 [the embedded hardware name of the card reported back was exact - I was glad about that]

Said that it was assigned/was using IRQ 22 [this was exact - I was glad that this setting was exactly like mine]

[OK - digression...sudden thought... don't know where to look for this in KNOS...is the IRQ 22 being shared by other devices becised the EMU10k2 in KNOWS? IF so, would that make a difference?]

all of the parameters / settings / results read/reported whatever, were the same on my two cards, and also the code bit I found...so I guess that means that my cards themselves are functioning ok in free-BSD [these were exact - if I remember correctly. Again, means simply the card are the same]

[on something i think i remember seeing] AC97 detected unable to load nonexistant or something [Exact same result as my boards. NOW - unless I am mistaken...and I'll go ahead right now and say that I am 100% wrong when I've completed this thought.....if the cards are the same, and the results are the same - as reported by the name of the cards, the reading of the parameters and settings, and the AC97 onboard audio chips are being searched for but being reported as non-existant; even if the other person's motherboard was INTEL, or INTEL OEM'd

OK - just an extremely crazy digression from someone who knows nothing about programming hardware. So please forgive me.


it used a different area of ram to map for the input-output - have no idea why or if that would make ANY difference...EXCEPT for the one question in my mind - would the fact that I set the PCI slot to IRQ 11 [this is also a DMA Busmaster card] and this card is supposedly NOT sharing IRQ's with other PCI slots make a difference....and I didn't pay attention to the site ...don't remember if there was info on the programmers' motherboard....

These were the "familiar" things

The "unfamiliar' things were the code for - I believe it referred to"loading the back end of the card" - the listings were dealing
with the EMU-DSP [among other things multi-channel with the Audiodock or the ADAT lightpipe]. These were also extremely interesting....[also has me wondering....will I be able to find the Linux drivers again, or the Linux apps? They used to be on the EMU site, but have been removed, along with all but the latest drivers..... ]

Anyway - nothing bad or untoward meant....Just that I was seeing something online that I understood a tiny bit of because of what I had seen in the KNOS diag.....

[Kevin McAleavey]

No need to worry about any of that with us ... when we first undertook this KNOS Project, we shook our heads and realized that going that route would be nothing short of a nightmare. Heh.

We gather the information as I explained in the other thread, but we went entirely our own way with the information. Welcome to the madness of the details though that has had me in many states of agita for the past couple of years getting this all together. The way we handle things, upon bootup we let the kernel do all of its probing and detecting and such but in the end all we do is take the information that the kernel bootup has gathered and use that information for KNOS' "smarts" to figure out what to do with it all. If KNOS and its BSD core makes it to the end of bootup without something actually messing up the kernel itself, we then sift through all the data, configure drivers, configure "userland," configure networking, configure sound, video, keyboard and mouse and then go forward to the desktop with our own interpretation of what we've been told about any particular hardware and the order we bring it up in to arrive at the desktop.

The way we've gone about it probably won't be of any help to someone trying to sort out BSD on their own, and since BSD has almost ZERO resemblance to Linux, definitely won't be of any help to them at all. I expect that once we get past the "dead motherboard sound" your EMU should wake up fat, dumb and happy in KNOS without any playing around other than doing the settings you want in the volume control applet on your desktop. In all seriousness, try enabling the AC97 in BIOS ... I'm still hoping that this will get you going for now until I can get the new code out with our next release ... hopefully that will do the trick for now ... otherwise, it'll be fixed for you on our next release. The code I've reworked is already done for that one.

[musicman]

have sent 4 diags & notes for the PESVL machine - this one. Now that I know that this is more-or-less about to be fixed...I am also going to check to see if I can locate anything for the Dell Emu that Jerry has - I am curious about this also..

ok - one question..in BSD or KNOS- is there the ability to load additional audio codecs if allowed / needed for a media player? I know that all codecs - at least in Windows - are NOT created the same, even for the same file format extension - and it shows up in PLAYBACK. Just wondering - am already trying to find out on my own...

[thinking ahead for when the sound is up and operative]

[Kevin McAleavey]

Dec 17, 2010 13:06:11 GMT -5 musicman said:

have sent 4 diags & notes for the PESVL machine - this one. Now that I know that this is more-or-less about to be fixed...I am also going to check to see if I can locate anything for the Dell Emu that Jerry has - I am curious about this also..

ok - one question..in BSD or KNOS- is there the ability to load additional audio codecs if allowed / needed for a media player? I know that all codecs - at least in Windows - are NOT created the same, even for the same file format extension - and it shows up in PLAYBACK. Just wondering - am already trying to find out on my own...

[thinking ahead for when the sound is up and operative]

KNOS contains all known codecs with the exception of RealNetworks' stuff (they refuse to permit redistribution and they also have major security issues) and the DVDCSS libraries because MPAA wants us to cut them a check for every free copy we hand out and that's not practical financially.

We include every single OTHER codec that you would find in the Windows' ffdshow or VLC distributions from AAC to WMV and everything in between. Same for data compression formats from 7Z to ZIP. Yes, we even do FLAC audio and some of the more exotic ones. Once we've got sound on your end, you'll be quite pleased.

As for Jerry (if we're thinking about the same one here) he's more interested in anyone else getting their Toshiba laptop running. Toshibas unfortunately didn't follow their own ACPI standards and his won't boot. If that's the "Jerry" we're talking about.

[Kevin McAleavey]

OK ... finally got the answers I needed on this one from Yuriy (the maintainer for the EMU drivers) as well as Orlando (who supplied the patches for what *is* supported) and the bad news is that this card is just NOT supported at all.

The reason for the AC97 madness is that all of these Audigy cards have AC97 controllers on them, but not THIS one. There are no OSS4 nor BSD drivers designed for it primarily because it's not a sufficiently popular card for anyone in the "community" to have been able to hack it. Documentation on the hardware is also absent, leaving the coders no way to have written a driver for it. I'm told that making matters even worse, since it's the same chipset that's used in all of the AC97-controlled cards out there, it would be a nightmare to support even if the technical details were available to them.

So that's the story and it explains all of the strangeness we've observed. The chipset ID (which according to the coders SHOULD have been changed to reflect its nonstandard nature) is causing the driver to attempt to load the AC97 controller but that card and the other ASIO-based cards in that family do not have any AC97 and that's what's causing the attach failure because the driver has nothing on the card to talk to. Apparently EMU wrote special drivers for it and the only solution would be for them to write one for the BSD's. Somehow I don't see that happening.

Sorry to be the bearer, but nothing I can do here.

Will get to your lengthy email once I grab something to eat ...

(Edit: Yuriy just pointed me to the source code entry on this) ...

/ * Unsupported cards * /

static struct emu_hwinfo emu_bad_cards [] = {
/ * APS cards should be possible to support * /
{0x1102, 0x0002, 0x1102, 0x4001, "EMUAPS", "E-mu APS", 0};
{0x1102, 0x0002, 0x1102, 0x4002, "EMUAPS", "E-mu APS", 0};
{0x1102, 0x0004, 0x1102, 0x4001, "EMU "," E-mu 1212m [4001] ", 0}, <------------ your card.
/ * Similar-named ("Live!" Or "Audigy") cards on different chipsets * /
{0x1102, 0x8064, 0x0000, 0x0000, "SB0100", "SBLive! 5.1 OEM", 0};
{0x1102, 0x0006, 0x0000, 0x0000, "SB0200", "DELL OEM SBLive! Value", 0};
{0x1102, 0x0007, 0x0000, 0x0000, "SB0310", "Audigy LS", 0};
};