EWX 24/96 SPDIF input problem with 0.9.4 (and "compiler.h")

EWX 24/96 SPDIF input problem with 0.9.4 (and "compiler.h")

[Denis Sbragion]

Hello all,

I found that the SPDIF input on my TerraTec EWX 24/96 no longer works with 
the latest 0.9.4 drivers. I digged into the cs8427.c code and I found that 
this lines in function 'snd_cs8427_create' of version 0.9.3:

...
/* CS8427_REG_RECVERRMASK: unmask the input PLL clock, V, confidence, 
biphase, parity status bits */
/* CS8427_UNLOCK | CS8427_V | CS8427_CONF | CS8427_BIP | CS8427_PAR,
Why setting CS8427_V causes clicks and glitches? */
CS8427_UNLOCK | CS8427_CONF | CS8427_BIP | CS8427_PAR,
...

have been changed into:

...
/* CS8427_REG_RECVERRMASK: unmask the input PLL clock, V, confidence, 
biphase, parity status bits */
/* CS8427_UNLOCK | CS8427_V | CS8427_CONF | CS8427_BIP | CS8427_PAR, * /
0xff, /* set everything */
...

in version 0.9.4, along with some other changes. The "Why setting CS8427_V 
causes clicks and glitches?" comment of version 0.9.3 comes from an old 
patch I sent to Jaroslav many months ago, when I had a similar problem with 
an older 0.9.0something version of the drivers. The fact that this patch 
has been rolled back makes me think that there are some other cards out 
there that need that flag, so I think that a card dependent intialization 
is needed here, but I don't know how to code it. Of course I'm willing to 
help in coding and testing everything that may be needed to make the driver 
run, though I can only test on my own EWX. Relevant environment: RedHat 
Linux 7.2, 2.4.7 kernel.
	I found also that the adriver.h file in version 0.9.4 includes the file 
"linux/compiler.h", which is not present on older 2.4 kernels like my 
2.4.7. Everything seems to compile pretty well even without this include, 
at least on 2.4.7, so may be a conditional inclusion is needed here.
	Finally, many thanks to all the ALSA development team for all its great 
work! Hope this could help improve this great work even more.

Regards,
--
	Denis Sbragion
	InfoTecna
	Tel: +39 0362 805396, Fax: +39 0362 805404
	URL: http://www.infotecna.it



-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php

Re: EWX 24/96 SPDIF input problem with 0.9.4 (and "compiler.h")

[Takashi Iwai]

Hi,

At Tue, 17 Jun 2003 09:50:29 +0200,
Denis Sbragion wrote:
> 
> Hello all,
> 
> I found that the SPDIF input on my TerraTec EWX 24/96 no longer works with 
> the latest 0.9.4 drivers. I digged into the cs8427.c code and I found that 
> this lines in function 'snd_cs8427_create' of version 0.9.3:
> 
> ...
> /* CS8427_REG_RECVERRMASK: unmask the input PLL clock, V, confidence, 
> biphase, parity status bits */
> /* CS8427_UNLOCK | CS8427_V | CS8427_CONF | CS8427_BIP | CS8427_PAR,
> Why setting CS8427_V causes clicks and glitches? */
> CS8427_UNLOCK | CS8427_CONF | CS8427_BIP | CS8427_PAR,
> ...
> 
> have been changed into:
> 
> ...
> /* CS8427_REG_RECVERRMASK: unmask the input PLL clock, V, confidence, 
> biphase, parity status bits */
> /* CS8427_UNLOCK | CS8427_V | CS8427_CONF | CS8427_BIP | CS8427_PAR, * /
> 0xff, /* set everything */
> ...
> 
> in version 0.9.4, along with some other changes. The "Why setting CS8427_V 
> causes clicks and glitches?" comment of version 0.9.3 comes from an old 
> patch I sent to Jaroslav many months ago, when I had a similar problem with 
> an older 0.9.0something version of the drivers. The fact that this patch 
> has been rolled back makes me think that there are some other cards out 
> there that need that flag, so I think that a card dependent intialization 
> is needed here, but I don't know how to code it. Of course I'm willing to 
> help in coding and testing everything that may be needed to make the driver 
> run, though I can only test on my own EWX. Relevant environment: RedHat 
> Linux 7.2, 2.4.7 kernel.

thanks for spotting this out.

as you suggested above, i added the ews-specific initialization
there.  it just resets the RECVERRMASK register afterwards in
ews.c.  please try the cvs version.


> 	I found also that the adriver.h file in version 0.9.4 includes the file 
> "linux/compiler.h", which is not present on older 2.4 kernels like my 
> 2.4.7. Everything seems to compile pretty well even without this include, 
> at least on 2.4.7, so may be a conditional inclusion is needed here.

this should have been fixed on the cvs.  it will create a dummy
linux/compiler.h if not found.


ciao,

Takashi


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01

Re: EWX 24/96 SPDIF input problem with 0.9.4 (and "compiler.h")

[Jaroslav Kysela]

On Mon, 30 Jun 2003, Takashi Iwai wrote:

> Hi,
> 
> At Tue, 17 Jun 2003 09:50:29 +0200,
> Denis Sbragion wrote:
> > 
> > Hello all,
> > 
> > I found that the SPDIF input on my TerraTec EWX 24/96 no longer works with 
> > the latest 0.9.4 drivers. I digged into the cs8427.c code and I found that 
> > this lines in function 'snd_cs8427_create' of version 0.9.3:
> > 
> > ...
> > /* CS8427_REG_RECVERRMASK: unmask the input PLL clock, V, confidence, 
> > biphase, parity status bits */
> > /* CS8427_UNLOCK | CS8427_V | CS8427_CONF | CS8427_BIP | CS8427_PAR,
> > Why setting CS8427_V causes clicks and glitches? */
> > CS8427_UNLOCK | CS8427_CONF | CS8427_BIP | CS8427_PAR,
> > ...
> > 
> > have been changed into:
> > 
> > ...
> > /* CS8427_REG_RECVERRMASK: unmask the input PLL clock, V, confidence, 
> > biphase, parity status bits */
> > /* CS8427_UNLOCK | CS8427_V | CS8427_CONF | CS8427_BIP | CS8427_PAR, * /
> > 0xff, /* set everything */
> > ...
> > 
> > in version 0.9.4, along with some other changes. The "Why setting CS8427_V 
> > causes clicks and glitches?" comment of version 0.9.3 comes from an old 
> > patch I sent to Jaroslav many months ago, when I had a similar problem with 
> > an older 0.9.0something version of the drivers. The fact that this patch 
> > has been rolled back makes me think that there are some other cards out 
> > there that need that flag, so I think that a card dependent intialization 
> > is needed here, but I don't know how to code it. Of course I'm willing to 
> > help in coding and testing everything that may be needed to make the driver 
> > run, though I can only test on my own EWX. Relevant environment: RedHat 
> > Linux 7.2, 2.4.7 kernel.
> 
> thanks for spotting this out.
> 
> as you suggested above, i added the ews-specific initialization
> there.  it just resets the RECVERRMASK register afterwards in
> ews.c.  please try the cvs version.

Sorry for late reply. My EWS 24/96 does not have this problem. I suggest 
to create a control which will turn on/off the V bit checking. I also 
suggest to verify the cable connection.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01

Re: EWX 24/96 SPDIF input problem with 0.9.4 (and "compiler.h")

[Denis Sbragion]

Hello Jaroslav and Takashi,

At 16.53 30/06/2003 +0200, Jaroslav Kysela wrote:
...
>Sorry for late reply. My EWS 24/96 does not have this problem. I suggest
>to create a control which will turn on/off the V bit checking. I also
>suggest to verify the cable connection.

don't worry for the late reply, I know you're always so busy with the many 
ALSA development tasks. I'm not in a hurry cause I can always switch back 
to 0.9.3. In the meantime I've done many tests that may help find where the 
problem is. Here are some informations:

- I tested using BruteFIR and arecord. Things change between the two.
- Using the 0.9.4 drivers "downgraded" with just the cs8427 module from 
0.9.3, both BF and arecord work like a charm.
- Using the 0.9.4 cs8427 module arecord works but BF doesn't. No error pops 
up, BF just wait forever for samples to come in.
- If I try arecord immediately after killing BF it doesn't work either, 
again no error, just endless wait. But if I go to alsamixer and switch the 
sample rate from SPDIF to any value and then back to SPDIF before starting 
arecord, arecord starts to work again.

Of course I've already double checked any cabling problem.

I digged into BF to see if it does something weird that may fools the 
driver, even disabling parts of the code to see if there's any particular 
action that cause the driver to fail, but had no success. What BF does is 
not that much different from what arecord does, at least it looks ok to me, 
though I'm not an expert with ALSA programming. I checked also the driver 
to see if there's something wrong with the new reset code, double checking 
it against the newest cs8427 data sheet where the reset procedure is 
explained, but also here everything looks ok. I tried disabling just the V 
bit, and played also with many other cs8427 settings, but again no success. 
I also upgraded from the old 2.4.7 kernel to a newest 2.4.20, and nothing 
has changed.
         Some other informations. The V bit with older drivers caused 
problems only when lowering the volume on my CD player, which changes also 
the SPDIF output volume (pretty weird, I know). Below a given threshold the 
soundcard started with glitches and distortion, muting completely if I 
lowered the volume a bit more. So may be it's just the CDP that outputs 
something that the cs8427 sees as invalid. Anyway listening to the sound 
with the V bit disabled doesn't show any audible distortion even well below 
the glitching threshold, but may be the cs8427 is catching something which 
is not audible under normal conditions. I think the suggestion of creating 
a control to switch the V bit on and off would be an ideal solution.
         Finally some other small bugs which you may be interested in fixing:

- If I load the ice1712 driver and sets the DAC volumes to 100% using 
"alsactl restore" from a prevoius "alsactl store" the right channel remains 
muted. Alsamixer reports it as being at 100%, but no sound from it. I have 
to change the volume back  using amixer or alsamixer to get the channel 
unmuted. This is laying around since 0.9.0rc5. It's just an annoying quirk. 
I already checked in the drivers to see if there's something wrong but 
found nothing.
- If I set the volume of the ADCs to 0, do an "alsactl store" and then an 
"alsactl restore", the ADC volume of both channels is set to 101, when 100 
should be the maximum value, but both ADCs are anyway muted. This has 
started since 0.9.2 or 0.9.1, I'm not sure, but was not present in 0.9.0rc5.
- The sample rate loops between 48000 to 8000 when changed from alsamixer 
in one direction, go up to 96000, then SPDIF and the stop with no looping 
there when changed the other way around.

Hopes this helps. I hope to have the time to check the CVS version. 
Unfortunately I'm a bit busy.

Bye,
--
	Denis Sbragion
	InfoTecna
	Tel: +39 0362 805396, Fax: +39 0362 805404
	URL: http://www.infotecna.it



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01