Re: [Alsa-devel] Envy24HT mixer restore problem with M-Audio Revolution 7.1 + Alsa 1.0.4
Hello Stephen,
At 20.24 12/04/2004 -0700, Stephen Hassard wrote:
When I set my 'DAC' and 'DAC1' channels to sane values (they correspond to
L+R audio) and save my mixer settings via 'alsactl store', reboot and
restore the settings via 'alsactl restore', my mixer settings appear to be
normal in alsamixer, but I find that my left channel ('DAC') is mutted
until I change the volume of 'DAC'. As soon as I touch the mixer for the
'DAC' channel, audio output is restored.
I have the exact same problem with a TerraTec EWX 24/96 (ice1712 AKA not HT
Envy24), though on the right channel. In my case this is a long lasting
quirk (easy to solve with a simple amixer call), cause it's there since at
least 0.9.0. I also checked the driver code sometimes sgo but haven't been
able to find any problem in the code.
Bye,
--
Denis Sbragion
InfoTecna
Tel: +39 0362 805396, Fax: +39 0362 805404
URL: http://www.infotecna.it
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Minor Revo Bug
Hello Mark,
At 15.06 21/10/2003 +0100, you wrote:
>The left front channel is always mute when the M-Audio Revolution
>(ice1724) driver is started/restarted with all mixer settings saved
>on exit. The other channels are fine.
>Moving the DAC volume slider in alsamixer unmutes this channel.
I should add:
1) This bug does not exist in version 0.9.6, so it probably has
something to do with the recent bug fixes in ice1724?
2) Volume settings are restored correctly in alsamixer on startup but
the left front channel is mute until the DAC volume slider is moved
up or down.
may be this could help: this exact same thing happens also with the
Terratec EWX 24/96 (ice1712), but on the right channel. This small quirk is
lasting since 0.9.0rc5 with the EWX. I tryed to find the source of the
problem myself, but I've never been hable to indentify a real bug, either
in the driver or in alsactl.
Bye,
--
Denis Sbragion
InfoTecna
Tel: +39 0362 805396, Fax: +39 0362 805404
URL: http://www.infotecna.it
---
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] EWX 24/96 and SPDIF: solved? (with patch)
Hello Jaroslav,
At 13.45 30/09/2003 +0200, Jaroslav Kysela wrote:
...
But I think that we still need to investigate why the second reset of
the CS8427 chip failed.
I have double checked your reset code comparing it with the latest data
sheet, where the weird reset procedure is explained, and in my opinion your
code is ok. May be this is just a one time procedure, which avoid the
CS8427 startup problem only the first time it is executed? This seems to be
loosely confirmed by the fact that if I unload the 8427 kernel module
(downloading the ICE module first, which uses it) and then reload it,
sometimes I get weird behaviours, with problems settings the period
size/buffer size both by arecord and BruteFIR. I know, it seems an
unrelated problem. I'm supposing here a failure in the 8427 code causing
also a problem elsewhere.
Anyway, I still don't understand why this second reset is needed,
base also on the rate value. When the SPDIF is the master clock the rate is
defined by the input SPDIF stream, so comparing it with the rate requested
by the program makes no sense to me. Of course I don't know the ALSA
architecture enough to be sure that doing it it's really a bug.
Bye,
--
Denis Sbragion
InfoTecna
Tel: +39 0362 805396, Fax: +39 0362 805404
URL: http://www.infotecna.it
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] EWX 24/96 and SPDIF: solved? (with patch)
Hello Jaroslav and Takashi, may be I finally nailed down the SPDIF problem with the TerraTec EWX 24/96. The problem is caused by the execution of a second CS8427 reset in the snd_cs8427_iec958_pcm() function in the cs8427.c file, exactly in the following lines of code: ... reset = chip->rate != rate; snd_i2c_unlock(cs8427->bus); if (reset) snd_cs8427_reset(cs8427); ... Anyway, I think the problem arise elsewhere, within the ice1712.c file, in the snd_ice1712_playback_pro_hw_params(), where there are the following lines of code: ... if (ice->spdif.ops.setup_rate) ice->spdif.ops.setup_rate(ice, params_rate(hw_params)); ... where the spdif rate is changed without checking if the rate is locked or not, i.e. without verifying if the is_pro_rate_locked() function returns true. Attached to this e-mail there's the obvious patch for this problem, changing the previous line into: ... if (ice->spdif.ops.setup_rate && !is_pro_rate_locked(ice)) ice->spdif.ops.setup_rate(ice, params_rate(hw_params)); ... With this patch my EWX works flawless with ALSA 0.9.7, anyway I can't check if it is going to cause problems with other ICE1712 based soundcards. I hope this change is the right one, and not something that makes just my soundcard work. Bye, ice1712.dif Description: Binary data -- Denis Sbragion InfoTecna Tel: +39 0362 805396, Fax: +39 0362 805404 URL: http://www.infotecna.it
Re: [Alsa-devel] M-Audio Revolution 7.1 card hangups
Hello Takashi, At 19.59 10/09/2003 +0200, you wrote: ... > 2) I use 'alsamixer'. Works fine. One problem: When I set the > conversion rate to the SPDIF clock (it has another name IEC...) IT > LOCKS AND STAYS THERE. No amount of diddling in 'alsamixer' yields > anything. To get around this I revert back to an older setting (it is > a long process) saved with 'alsactl' after a reboot. While I have > learned my lesson (DON'T DO THAT!), the behavior is not too good. ok, that's easy. please apply the patch attached. ... is this problem somewhat related to the SPDIF problem I found with my TerraTec EWX 24/96? I haven't been able to solve it, but, to tell the true, I haven't tried really hard. Just digged a little in the source code. Actually I'm still running with 0.9.4 plus the cs8427 module from 0.9.3. Bye, -- Denis Sbragion InfoTecna Tel: +39 0362 805396, Fax: +39 0362 805404 URL: http://www.infotecna.it --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] EWX and SPDIF, can you take a look at this?
Hello Takashi,
At 12.50 02/07/2003 +0200, you wrote:
...
yes. the API was changed quite ago.
ok, thanks. So the problem is somewere else. It's becoming quite a
challenging task...
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/psa0016ave/direct;at.asp_061203_01/01
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] EWX and SPDIF, can you take a look at this?
Hello,
may be unrelated or not. I noticed that in aplay.c (0.9.4), at line 818,
the sample rate setting is obtained with:
rate = hwparams.rate;
err = snd_pcm_hw_params_set_rate_near(handle, params, &hwparams.rate, 0);
Is it correct to use a reference (&) to set the sample rate? Looking at the
hwparams structure and the snd_pcm_hw_params_set_rate_near definition I
think this should be just:
err = snd_pcm_hw_params_set_rate_near(handle, params, hwparams.rate, 0);
BruteFIR set the sample rate with:
/* It seems like it is best to set_rate_near instead of exact, have had
problems with ens1371 */
if ((err = snd_pcm_hw_params_set_rate_near(handle, params,
sample_rate, 0)) < 0)
{
...
No & here. I think either one or the other is a bug. This is the only
relevant difference I found between the BF initialization sequence and the
arecord one, so it may be related with the SPDIF problem with the EWX
considering the different behaviour between the two.
Thanks for the attention, and sorry if this is just a mistake in my
understanding on how ALSA works.
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/psa0016ave/direct;at.asp_061203_01/01
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] EWX 24/96 SPDIF input problem with 0.9.4 (and "compiler.h")
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/psa0016ave/direct;at.asp_061203_01/01 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] EWX 24/96 SPDIF input problem with 0.9.4 (and "compiler.h")
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 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
