Re: [PATCH] Gallant SC-6000 driver (4th version)

Re: [PATCH] Gallant SC-6000 driver (4th version)

[Krzysztof Helt]

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&sid=15

Re: [PATCH] Gallant SC-6000 driver (4th version)

[Rene Herman]

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.

Re: [PATCH] Gallant SC-6000 driver (4th version)

[Rene Herman]

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.

Re: [PATCH] Gallant SC-6000 driver (4th version)

[Krzysztof Helt]

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.html&sid=12

Re: [PATCH] Gallant SC-6000 driver (4th version)

[Rene Herman]

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH] Gallant SC-6000 driver (4th version)

[Krzysztof Helt]

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

Re: [PATCH] Gallant SC-6000 driver (4th version)

[Rene Herman]

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.

Re: full duplex AD1848 (was SC-6000 driver)

[Krzysztof Helt]

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

Re: [PATCH] Gallant SC-6000 driver (4th version)

[Takashi Iwai]

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

Re: full duplex AD1848 (was SC-6000 driver)

[Rene Herman]

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.

Re: [PATCH] Gallant SC-6000 driver (4th version)

[Rene Herman]

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.