Re: [alsa-devel] [PATCH] Gallant SC-6000 driver (4th version)
Rene Herman wrote:
On 09/05/2007 10:25 PM, Krzysztof Helt wrote:
I have left the ISA autodetection. It makes driver usage
simpler for user.
The base port, mpu port and mss port can be read from jumper
settings,
but irq or dma is not settable. A system may figure out which
one is free
and use it.
The problem is that this "simplification" might actually leave
the non-aware
user scratching his head for far longer than if he has to spell
things out.
I know it may not work all the time, but you can always fall back to giving number. If the simple autodetection works, it helps.
Even without that problem, we have the problem of IRQs that's
only _appear_
to be free. IRQ7 for example will usually be assigned to the
first parallel
port but will only show up as taken if the parport driver is
loaded. Often,
it'll still actually work, but (again) here for example, it
does not.
Actually, the parport_pc driver is loaded by the udev by default, so the IRQ7 cannot be requested (I tested - IRQ7 request failed even if I had not used the printer).
It's not like people using legacy ISA in this day and age are
not normally
nerds anyway...
That's the best argument.
Yes. I am looking at the sound galaxy driver at the moment and
am in fact
now trying to think of why I want to use the WSS part of the
card and not
just the SBP part. In DOS, the card is setup in SB Pro mode by
default as
well, and the CS42xx seems to only be present really for
Windows Sound
System compatibility for old 16-bit Windows.
IIRC from SB Pro times, the SB Pro specification said it supported only 16 bit of output (ment either 16-bit mono or 8-bit stereo). The SB16 supported stereo 16-bit audio. I don't know what is expected from WSS, but if the SB Pro mode gives full duplex 16-bit stereo, there is no reason to use WSS mode.
(I do not have the CS4231 based card but I should have it next
week -
Sound Galaxy Waverider).
Am testing on that one currently -- will post the driver before
next week.
I'll be happy to test it too.
Quite sure that 5 works by the way? On a Sound Galaxy, 5 only
works for the
SB part (and 11 only for the WSS).
It is the IRQ found most times as the first free during card tests. It worked on all free IRQs from the range (the 10 or 11 is occupied by USB/PS2 and I haven't bothered to make it free). It seems that ASC-9308 is more capable (in this respect) than SG chips.
Regards, Krzysztof
---------------------------------------------------- Pierwsza od piętnastu lat książka Václava Havla "Tylko krótko proszę" - już w księgarniach! http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fhavel.html&...
On 09/06/2007 08:49 AM, Krzysztof Helt wrote:
Actually, the parport_pc driver is loaded by the udev by default, so the IRQ7 cannot be requested (I tested - IRQ7 request failed even if I had not used the printer).
Not everybody uses udev. But more importantly, only if the hardware in question is discoverable. A parallel port will these days normally be advertised using PnP (BIOS/ACPI) in fact which puts it on the same footing as ISA-PnP and PCI with respect to this issue, but we are specifically discussing this in the context of legacy ISA cards.
So imagine you have another piece of legacy ISA hardware sitting on the resources. Nothing will tell your driver that it is occupying the resources in question so it goes ahead and grabs them after which both your hardware and the other one fail, leaving this poor unaware user for whom autoprobing is supposedly helpful clueless as to why nothing works.
Then there's the bit about this user generally needing to know what resource is going to be assigned so he can reserve it in the BIOS anyway. Without, an IRQ may not even be useable from the ISA bus on some systems.
And _then_ there's the bit about the ISA probing being a huge gaping race by design. There's really no defending that massive junk. All ISA autoprobing is bad engineering and should be ripped out and shot, period. It's broken both by design and implementation. The solution to making things nicer is not autoprobing but not using legacy ISA -- and basically noone is other than for entertainment purposes.
Any system with ISA slots and running a modern kernel support ISA-PnP or PnP-BIOS for onboard chips (and not to mention PCI) which solves the problem nicely through being discoverable. Us entertainment-value users do not feel there's anything wrong with sticking
options snd-foo port=0x220 irq=5 dma=1
in /etc/modprobe.conf
I don't know what is expected from WSS, but if the SB Pro mode gives full duplex 16-bit stereo, there is no reason to use WSS mode.
Full duplex (simultaneous playback and capture) is something that neither Sb Pro nor CS4231 does. I do see that SB Pro doesn't natively support S16_LE it seems...
Quite sure that 5 works by the way? On a Sound Galaxy, 5 only works for the SB part (and 11 only for the WSS).
It is the IRQ found most times as the first free during card tests. It worked on all free IRQs from the range (the 10 or 11 is occupied by USB/PS2 and I haven't bothered to make it free). It seems that ASC-9308 is more capable (in this respect) than SG chips.
Okay, so it's at least in some respects really different. That probably means a seperate driver makes sense.
Rene.
On 09/06/2007 12:12 PM, Rene Herman wrote:
Full duplex (simultaneous playback and capture) is something that neither Sb Pro nor CS4231 does. I do see that SB Pro doesn't natively support S16_LE it seems...
Sorry, incorrect -- the cs4231 is full duplex. It's only the cs4248 (ad1848) which is not. Need to figure out how to do full duplex on a sound galaxy; old driver didn't do so.
Rene.
On Thu, 06 Sep 2007 12:12:42 +0200 Rene Herman rene.herman@gmail.com wrote:
On 09/06/2007 08:49 AM, Krzysztof Helt wrote:
Actually, the parport_pc driver is loaded by the udev by default, so the IRQ7 cannot be requested (I tested - IRQ7 request failed even if I had not used the printer).
Not everybody uses udev. But more importantly, only if the hardware in question is discoverable. [...]
And _then_ there's the bit about the ISA probing being a huge gaping race by design. There's really no defending that massive junk. All ISA autoprobing is bad engineering and should be ripped out and shot, period. It's broken both by design and implementation. The solution to making things nicer is not autoprobing but not using legacy ISA -- and basically noone is other than for entertainment purposes.
I am quite sure we won't agree on this one. My reason (to keep autodection) is sheer laziness of giving two numbers. Even giving them does not make user free of problems how to avoid irqs and dmas with installed devices but not visible in the /proc/interrupts file).
I would like to ask Takashi to decide on this issue. I will done as he says.
Will this driver be included? I found a bug in probing - if something is wrong after the SB region is requested it won't be released. So the next version is needed to be done anyway (or a small patch later).
Regards, Krzysztof
On 09/06/2007 11:12 PM, Krzysztof Helt wrote:
On Thu, 06 Sep 2007 12:12:42 +0200 Rene Herman rene.herman@gmail.com wrote:
On 09/06/2007 08:49 AM, Krzysztof Helt wrote:
Actually, the parport_pc driver is loaded by the udev by default, so the IRQ7 cannot be requested (I tested - IRQ7 request failed even if I had not used the printer).
Not everybody uses udev. But more importantly, only if the hardware in question is discoverable. [...]
And _then_ there's the bit about the ISA probing being a huge gaping race by design. There's really no defending that massive junk. All ISA autoprobing is bad engineering and should be ripped out and shot, period. It's broken both by design and implementation. The solution to making things nicer is not autoprobing but not using legacy ISA -- and basically noone is other than for entertainment purposes.
I am quite sure we won't agree on this one. My reason (to keep autodection) is sheer laziness of giving two numbers. Even giving them does not make user free of problems how to avoid irqs and dmas with installed devices but not visible in the /proc/interrupts file).
No, but then at least you aren't hiding the problem by promising the user to figure it all out automatically. And as said, /etc/modprobe.conf works...
I would like to ask Takashi to decide on this issue. I will done as he says.
Oh, I've not much doubt he'll not mind it terribly. Still many drivers in sound/isa that do probing. Doesn't change that it's all counter-productive, broken junk though!
Will this driver be included? I found a bug in probing - if something is wrong after the SB region is requested it won't be released. So the next version is needed to be done anyway (or a small patch later).
Still testing with snd-galaxy here and haven't really looked at integrating them yet. Will do, but I believe I saw some differences stand out already.
Rene.
At Thu, 06 Sep 2007 23:16:39 +0200, Rene Herman wrote:
On 09/06/2007 11:12 PM, Krzysztof Helt wrote:
On Thu, 06 Sep 2007 12:12:42 +0200 Rene Herman rene.herman@gmail.com wrote:
On 09/06/2007 08:49 AM, Krzysztof Helt wrote:
Actually, the parport_pc driver is loaded by the udev by default, so the IRQ7 cannot be requested (I tested - IRQ7 request failed even if I had not used the printer).
Not everybody uses udev. But more importantly, only if the hardware in question is discoverable. [...]
And _then_ there's the bit about the ISA probing being a huge gaping race by design. There's really no defending that massive junk. All ISA autoprobing is bad engineering and should be ripped out and shot, period. It's broken both by design and implementation. The solution to making things nicer is not autoprobing but not using legacy ISA -- and basically noone is other than for entertainment purposes.
I am quite sure we won't agree on this one. My reason (to keep autodection) is sheer laziness of giving two numbers. Even giving them does not make user free of problems how to avoid irqs and dmas with installed devices but not visible in the /proc/interrupts file).
No, but then at least you aren't hiding the problem by promising the user to figure it all out automatically. And as said, /etc/modprobe.conf works...
I would like to ask Takashi to decide on this issue. I will done as he says.
Oh, I've not much doubt he'll not mind it terribly. Still many drivers in sound/isa that do probing. Doesn't change that it's all counter-productive, broken junk though!
The codes used for this auto-probing is relatively small and easy, so as Rene expected, I don't mind about it :)
The criterion is only whether it's _really_ useful and works without hitch. We keep the old code as is just because it was worked, and we shouldn't break it. The concept is not perfect, but if it practically works, I have no objection.
Will this driver be included? I found a bug in probing - if something is wrong after the SB region is requested it won't be released. So the next version is needed to be done anyway (or a small patch later).
Still testing with snd-galaxy here and haven't really looked at integrating them yet. Will do, but I believe I saw some differences stand out already.
I'm for merging it -- at least, if it's confirmed to work on the latest kernel (and the bug is fixed). Let's put all them in a pot before 1.0.15 final. We'll cook better after that.
thanks,
Takashi
On 09/07/2007 01:11 PM, Takashi Iwai wrote:
The codes used for this auto-probing is relatively small and easy, so as Rene expected, I don't mind about it :)
The criterion is only whether it's _really_ useful and works without hitch.
Exactly. Krysztof snipped most of my objections but we are talking about legacy ISA hardware here. So imagine you have _another_ piece of legacy ISA hardware sitting on say IRQ 5. Unless you load your driver after the driver for the other bit of hardware is loaded, your driver finds IRQ 5 free, grabs it and configures the card for IRQ 5, after which your nor the other piece of hardware work anymore.
At this point, you've helped this poor unaware user from the docks into the harbour as he has no idea what's going on, having not specified anything himself.
I'll repeat -- there's really no defending that massive junk :-)
We keep the old code as is just because it was worked, and we shouldn't break it. The concept is not perfect, but if it practically works, I have no objection.
What practically works is sticking an options line in modprobe.conf...
But hey, I'm aware some people think it helps. As long as you are aware you're wrong and that it _is_ massive junk, I'm halfway content :-)
Rene.
Dnia 6-09-2007 o godz. 13:20 Rene Herman napisał(a):
On 09/06/2007 12:12 PM, Rene Herman wrote:
Full duplex (simultaneous playback and capture) is something
that
neither Sb Pro nor CS4231 does. I do see that SB Pro doesn't
natively
support S16_LE it seems...
Sorry, incorrect -- the cs4231 is full duplex. It's only the
cs4248 (ad1848)
which is not. Need to figure out how to do full duplex on a
sound galaxy;
old driver didn't do so.
The SG Waverider is full duplex (at least Win95 driver says so).
Regards, Krzysztof
---------------------------------------------------- Walka jakiej nie widziałeś! KSW eliminacje, nie wszyscy przejdą cało! Zobacz na żywo we Wrocławiu już 15 września. Więcej -> http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fksweliminacje.h...
On 09/06/2007 04:03 PM, Krzysztof Helt wrote:
Dnia 6-09-2007 o godz. 13:20 Rene Herman napisał(a):
Sorry, incorrect -- the cs4231 is full duplex. It's only the cs4248 (ad1848) which is not. Need to figure out how to do full duplex on a sound galaxy; old driver didn't do so.
The SG Waverider is full duplex (at least Win95 driver says so).
Yup, figured it out -- it's working nicely. Sound Galaxies come with various codecs; also CS4248 which is half-duplex, so now only need to check that now _those_ don't crap out...
Rene
On Thu, 06 Sep 2007 17:18:07 +0200 Rene Herman rene.herman@gmail.com wrote:
On 09/06/2007 04:03 PM, Krzysztof Helt wrote:
Dnia 6-09-2007 o godz. 13:20 Rene Herman napisał(a):
Sorry, incorrect -- the cs4231 is full duplex. It's only the cs4248 (ad1848) which is not. Need to figure out how to do full duplex on a sound galaxy; old driver didn't do so.
According to a datasheet, the AD1848K (which was a popular version of AD1848) is full-duplex (can work in single-dma mode or with two dma channels).
The AD1848 in my SC-6000 is not the K version (at least it is not marked on the chip) but I saw a photo on the net with SC-6000 and AD1848K (it had no YMF-262 chip but a different one).
I am looking for the AD1848 datasheet for the pre-K version (or list of differences between K and earlier versions).
Also, I would like to know how you put your SG card into full-duplex mode.
It seems that hardware of AD1848/CS4231 was not used to its full potential (SB compatibility was more important).
Regards, Krzysztof
On 09/07/2007 10:34 AM, Krzysztof Helt wrote:
According to a datasheet, the AD1848K (which was a popular version of AD1848) is full-duplex (can work in single-dma mode or with two dma channels).
Yes, I see...
The AD1848 in my SC-6000 is not the K version (at least it is not marked on the chip) but I saw a photo on the net with SC-6000 and AD1848K (it had no YMF-262 chip but a different one).
I am looking for the AD1848 datasheet for the pre-K version (or list of differences between K and earlier versions).
Can also only find the K datasheet. Not sure what's up with that -- the existing ad1848 driver is simplex only.
Also, I would like to know how you put your SG card into full-duplex mode.
That may be the easiest test yes. Try setting bit 2 of mss_config (| 4). This seems to be the generic way to enable duplex on mss/wss and it works here. The capture channel is fixed for a fiven playback channel:
P = 0 ==> C = 1 P = 1 ==> C = 0 P = 3 ==> C = 0
By the way -- I'm running into a bug somewhere in cs4231_lib where sometimes the playback IRQ stops firing when you start a capture. Stopping both the capture and playback and then re-starting the playback works, after which things may or may not hang again at re-starting the capture.
Could also be a hardware bug I guess -- will need to test further again (sigh). But just in case you'd also run into this, don't give up on ful-duplex if it only sometimes doesn't work right, as there might very well be a bug lurking in cs4231_lib.
(bug cannot be in my own code, as that's just setup and nowhere to be found anymore when things are running).
Rene.
participants (4)
-
Krzysztof Helt -
Krzysztof Helt -
Rene Herman -
Takashi Iwai