Re: [Alsa-devel] Re: Phase Reversal on Santa Cruz (cs46xx) = XFiretoo
Hi Kevin, hi Benny, with your changes applied, now both PCM channels have the same phase with my XFire. The stereo image makes much more sense that way :-). Thanks a lot! What I've noticed: Switching the 'PCM Out' control from 'pre 3D' to 'post 3D' inverts the sign of both lr channels. (behaviour is independent of '3D depth', '3D center' and '3D switch' controls). But that doesn't cause any problems, at least with stereo output (which is the only mode the XFire works for now). With 2 channel output on other cs46xx cards this could perhaps cause problems if the phase of the rear/LFE/center channels doesn't match the left/right channel phase any more. But I can't check this with my card. @Benny: Another problem: SPDIF input doesn't work anymore since I applied the patch attached in your mail on 11/23/02. There is no 'SPDIF ac3 mode' in alsamixer after patching. Is this correct? And I noticed that I can't change the SPDIF input volume for left and right channel independently anymore. If I move the slider for one channel, the other follows more or less. I get a maximum volume difference of 4 (on the range 0..100) between left and right SPDIF input channel. Changing the levels independently and SPDIF input worked before patching. I reinstalled the unpatched rc6 driver but even restarting alsa didn't make SPDIF input working again (I also deleted my /etc/asound.state because the mixer controls have changed). Finally, I found out that I had to switch off my PC for several seconds and restart with the unpatched rc6 driver. The patched driver changes the state of the soundcard in some way that even reinstalling the unpatched one doesn't help without cold booting. Does SPDIF input work for other cs46xx based cards after applying the mentioned patch? What errors does this patch fix? Do I need it? Anyway, great to have pcm output without phase reversals. Thanks again! fe Benny Sjostrand schrieb: it seems that volumes 0-0x7fff ramp up volumes, then 8000- go back down... but with opposite phases. So... Great discovery!, probably the stream can be inverted several times when it processedthrough through the SCB tree. (PCMReader-SrcTaskSCB-MasterMixSCB-CodecOut) Almost all SCB's got a volume field. and it sounds correct (for CD analog passthru and PCM at least). (note - you'll need to open alsamixer and adjust the DAC volume before the 'fix' works, I haven't found where it gets programmed on driver load. I guess that the only thing left is to change the initial volume values set when driver is loaded in dsp_spos.c line 260: /* maximize volume */ ins-dac_volume_right = 0x8000; -ins-dac_volume_left = 0x8000; + ins-dac_volume_left = 0x7fff; ins-spdif_input_volume_right = 0x8000; -ins-spdif_input_volume_left = 0x8000; + ins-spdif_input_volume_left = 0x7fff; Now, I have no idea if this is correct, if I just broke SPDIF (no reciever), rear speakers (ditto, I don't have any) but it fixes my case anyway, so that's a start. If anyone can test more of these cases, that might be good. If it works and solves a problem then it must correct -:) /Benny --- 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] Re: Phase Reversal on Santa Cruz (cs46xx) = XFiretoo
Hi Benny,
I noticed the phase reversal problem with my Terratec XFire, too: I
played a mono wav. Then I combined the left and rigth output
electrically and the sound was gone, i.e. one channel outputs the sound
with a sign change, so that left+right=signal+(-signal)=0. The sound
went back when unbalancing the output level. (This would also explain
why my impulse response measuring program measures a negative response
when connecting line out to line in ;-). I use the left channel of the
soundcard for it.)
It applied your patch below, but it didn't solve the problem. Is it
correct that the SDPIF AC3 mode switch is gone after applying the patch?
I patched alsa version 0.9.0rc6.
fe
P.S. just tested my IR measuring program with right channel (and
0.9.0rc6) = positive response
P.S.S. now I really wanted to know which channel has wrong sign with
rc6. With 0.9.0rc2 I get positive impulse responses for both left and
right channel.
conclusion: the left pcm channel of the alsa 0.9.0rc6 driver for cs46xx
has wrong sign. Perhaps this can help a bit location the error.
Benny Sjostrand schrieb:
no, I haven't, since the patch is quite mangled in the www archive
and I wasn't subscribed then, I didn't go through th trouble of
fixing it up. Is it merged into cvs now, and if not, could you send
it my way? I'd be happy to give it a shot.
Here is the patch again, it's not in current CVS.
/Benny
diff --exclude=CVS -Naur alsa-kernel/include/cs46xx_dsp_spos.h ../cvs/alsa-kernel/include/cs46xx_dsp_spos.h
--- alsa-kernel/include/cs46xx_dsp_spos.h Sun Nov 10 19:47:01 2002
+++ ../cvs/alsa-kernel/include/cs46xx_dsp_spos.h Thu Nov 14 00:39:06 2002
@@ -63,7 +63,6 @@
#define DSP_SPDIF_STATUS_OUTPUT_ENABLED 1
#define DSP_SPDIF_STATUS_PLAYBACK_OPEN 2
#define DSP_SPDIF_STATUS_HW_ENABLED 4
-#define DSP_SPDIF_STATUS_AC3_MODE 8
struct _dsp_module_desc_t;
@@ -196,6 +195,10 @@
int spdif_status_in;
u16 spdif_input_volume_right;
u16 spdif_input_volume_left;
+ /* spdif channel status,
+ left right and user validity bits */
+ int spdif_csuv_default;
+ int spdif_csuv_stream;
/* SPDIF input sample rate converter */
dsp_scb_descriptor_t * spdif_in_src;
diff --exclude=CVS -Naur alsa-kernel/pci/cs46xx/cs46xx_lib.c ../cvs/alsa-kernel/pci/cs46xx/cs46xx_lib.c
--- alsa-kernel/pci/cs46xx/cs46xx_lib.c Mon Nov 11 23:04:50 2002
+++ ../cvs/alsa-kernel/pci/cs46xx/cs46xx_lib.c Sun Nov 17 16:26:53 2002
@@ -946,15 +946,15 @@
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_RESUME:
#ifdef CONFIG_SND_CS46XX_NEW_DSP
+ /* magic value to unmute PCM stream playback volume */
+ snd_cs46xx_poke(chip, (cpcm-pcm_channel-pcm_reader_scb-address +
+ SCBVolumeCtrl) 2, 0x80007fff);
+
if (cpcm-pcm_channel-unlinked)
cs46xx_dsp_pcm_link(chip,cpcm-pcm_channel);
+
if (substream-runtime-periods != CS46XX_FRAGS)
snd_cs46xx_playback_transfer(substream, 0);
-
- /* raise playback volume */
- cs46xx_dsp_scb_set_volume (chip,cpcm-pcm_channel-pcm_reader_scb,
- chip-dsp_spos_instance-dac_volume_right,
- chip-dsp_spos_instance-dac_volume_left);
#else
if (substream-runtime-periods != CS46XX_FRAGS)
snd_cs46xx_playback_transfer(substream, 0);
@@ -968,8 +968,9 @@
case SNDRV_PCM_TRIGGER_STOP:
case SNDRV_PCM_TRIGGER_SUSPEND:
#ifdef CONFIG_SND_CS46XX_NEW_DSP
- /* mute channel */
- cs46xx_dsp_scb_set_volume (chip,cpcm-pcm_channel-pcm_reader_scb,0,0);
+ /* magic mute channel */
+ snd_cs46xx_poke(chip, (cpcm-pcm_channel-pcm_reader_scb-address +
+ SCBVolumeCtrl) 2, 0x);
if (!cpcm-pcm_channel-unlinked)
cs46xx_dsp_pcm_unlink(chip,cpcm-pcm_channel);
@@ -1063,6 +1064,7 @@
}
#endif
+
static int snd_cs46xx_playback_hw_params(snd_pcm_substream_t * substream,
snd_pcm_hw_params_t * hw_params)
{
@@ -1079,15 +1081,10 @@
down (chip-spos_mutex);
snd_assert (cpcm-pcm_channel != NULL);
-
- /* if IEC958 is opened in AC3 mode dont adjust SRCTask is not
- used so dont adjust sample rate */
- if (cpcm-pcm_channel-pcm_channel_id != DSP_IEC958_CHANNEL ||
- !(chip-dsp_spos_instance-spdif_status_out DSP_SPDIF_STATUS_AC3_MODE)) {
- if (_cs46xx_adjust_sample_rate (chip,cpcm,sample_rate)) {
- up (chip-spos_mutex);
- return -ENXIO;
- }
+
+ if (_cs46xx_adjust_sample_rate (chip,cpcm,sample_rate)) {
+ up (chip-spos_mutex);
+ return -ENXIO;
}
if (cs46xx_dsp_pcm_channel_set_period (chip,cpcm-pcm_channel,period_size * 4)) {
@@ -1886,8 +1883,8 @@
{
cs46xx_t *chip = snd_kcontrol_chip(kcontrol);
- ucontrol-value.integer.value[0] = chip-dsp_spos_instance-dac_volume_right;
- ucontrol-value.integer.value[1] = chip-dsp_spos_instance-dac_volume_left;
+ ucontrol-value.integer.value[0] = chip-dsp_spos_instance-dac_volume_left;
+ ucontrol-value.integer.value[1] = chip-dsp_spos_instance-dac_volume_right;
return 0;
}
@@ -2038,34 +2035,6 @@
return 0;
}
-static int snd_cs46xx_iec958_ac3_mode_get(snd_kcontrol_t
Re: [Alsa-devel] Re: Phase Reversal on Santa Cruz (cs46xx) = XFire too
On Tuesday 03 December 2002 16:24, Friedrich Ewaldt wrote:
Hi Benny,
w00t!
it seems that volumes 0-0x7fff ramp up volumes, then 8000- go back down...
but with opposite phases. So...
--- alsa-cvs/alsa-driver-0.9.0rc6cvs20021202/alsa-kernel/pci/cs46xx/dsp_spos.h
2002-11-24 19:52:17.0 -0600
+++ modules/alsa-driver/alsa-kernel/pci/cs46xx/dsp_spos.h 2002-12-03
17:27:10.0 -0600
@@ -215,7 +215,7 @@
static inline void cs46xx_dsp_scb_set_volume (cs46xx_t *
chip,dsp_scb_descriptor_t * scb,
u16 left,u16 right) {
- unsigned int val = ((0x - left) 16 | (0x - right));
+ unsigned int val = (left 16 | (0x - right));
snd_cs46xx_poke(chip, (scb-address + SCBVolumeCtrl) 2, val);
snd_cs46xx_poke(chip, (scb-address + SCBVolumeCtrl + 1) 2, val);
and it sounds correct (for CD analog passthru and PCM at least).
(note - you'll need to open alsamixer and adjust the DAC volume before the
'fix' works, I haven't found where it gets programmed on driver load.
Now, I have no idea if this is correct, if I just broke SPDIF (no reciever),
rear speakers (ditto, I don't have any) but it fixes my case anyway, so
that's a start. If anyone can test more of these cases, that might be good.
Throwing it out before I head out here for a few hours, in the hope that it
will cause some insight :-)
---
This SF.net email is sponsored by: Microsoft Visual Studio.NET
comprehensive development tool, built to increase your
productivity. Try a free online hosted session at:
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: Phase Reversal on Santa Cruz (cs46xx) = XFiretoo
it seems that volumes 0-0x7fff ramp up volumes, then 8000- go back down... but with opposite phases. So... Great discovery!, probably the stream can be inverted several times when it processedthrough through the SCB tree. (PCMReader-SrcTaskSCB-MasterMixSCB-CodecOut) Almost all SCB's got a volume field. and it sounds correct (for CD analog passthru and PCM at least). (note - you'll need to open alsamixer and adjust the DAC volume before the 'fix' works, I haven't found where it gets programmed on driver load. I guess that the only thing left is to change the initial volume values set when driver is loaded in dsp_spos.c line 260: /* maximize volume */ ins-dac_volume_right = 0x8000; -ins-dac_volume_left = 0x8000; + ins-dac_volume_left = 0x7fff; ins-spdif_input_volume_right = 0x8000; -ins-spdif_input_volume_left = 0x8000; + ins-spdif_input_volume_left = 0x7fff; Now, I have no idea if this is correct, if I just broke SPDIF (no reciever), rear speakers (ditto, I don't have any) but it fixes my case anyway, so that's a start. If anyone can test more of these cases, that might be good. If it works and solves a problem then it must correct -:) /Benny --- This SF.net email is sponsored by: Microsoft Visual Studio.NET comprehensive development tool, built to increase your productivity. Try a free online hosted session at: http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: Phase Reversal on Santa Cruz (cs46xx)
Just as a general point to note. We are not putting the audio card into AC3 mode. We might be doing passthru mode or spdif non-audio, but never just AC3 mode. I help with the xine (a free media player http://xine.sf.net) that can play DVDs. DVDs have AC3 audio tracks and DTS audio tracks. xine uses spdif non-audio and passthru mode when used with alsa. It can therefore output AC3 and DTS tracks to an external decoder. Summary: - AC3 is the wrong term to use. spdif passthru is probably a better term to use, as the current ac3_mode seems to imply that DTS audio might not work. Cheers James --- 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] Re: Phase Reversal on Santa Cruz (cs46xx)
no, I haven't, since the patch is quite mangled in the www archive and I
wasn't subscribed then, I didn't go through th trouble of fixing it up. Is it
merged into cvs now, and if not, could you send it my way? I'd be happy to
give it a shot.
Here is the patch again, it's not in current CVS.
/Benny
diff --exclude=CVS -Naur alsa-kernel/include/cs46xx_dsp_spos.h
../cvs/alsa-kernel/include/cs46xx_dsp_spos.h
--- alsa-kernel/include/cs46xx_dsp_spos.h Sun Nov 10 19:47:01 2002
+++ ../cvs/alsa-kernel/include/cs46xx_dsp_spos.hThu Nov 14 00:39:06 2002
@@ -63,7 +63,6 @@
#define DSP_SPDIF_STATUS_OUTPUT_ENABLED 1
#define DSP_SPDIF_STATUS_PLAYBACK_OPEN 2
#define DSP_SPDIF_STATUS_HW_ENABLED 4
-#define DSP_SPDIF_STATUS_AC3_MODE 8
struct _dsp_module_desc_t;
@@ -196,6 +195,10 @@
int spdif_status_in;
u16 spdif_input_volume_right;
u16 spdif_input_volume_left;
+ /* spdif channel status,
+ left right and user validity bits */
+ int spdif_csuv_default;
+ int spdif_csuv_stream;
/* SPDIF input sample rate converter */
dsp_scb_descriptor_t * spdif_in_src;
diff --exclude=CVS -Naur alsa-kernel/pci/cs46xx/cs46xx_lib.c
../cvs/alsa-kernel/pci/cs46xx/cs46xx_lib.c
--- alsa-kernel/pci/cs46xx/cs46xx_lib.c Mon Nov 11 23:04:50 2002
+++ ../cvs/alsa-kernel/pci/cs46xx/cs46xx_lib.c Sun Nov 17 16:26:53 2002
@@ -946,15 +946,15 @@
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_RESUME:
#ifdef CONFIG_SND_CS46XX_NEW_DSP
+ /* magic value to unmute PCM stream playback volume */
+ snd_cs46xx_poke(chip, (cpcm-pcm_channel-pcm_reader_scb-address +
+ SCBVolumeCtrl) 2, 0x80007fff);
+
if (cpcm-pcm_channel-unlinked)
cs46xx_dsp_pcm_link(chip,cpcm-pcm_channel);
+
if (substream-runtime-periods != CS46XX_FRAGS)
snd_cs46xx_playback_transfer(substream, 0);
-
- /* raise playback volume */
- cs46xx_dsp_scb_set_volume (chip,cpcm-pcm_channel-pcm_reader_scb,
- chip-dsp_spos_instance-dac_volume_right,
- chip-dsp_spos_instance-dac_volume_left);
#else
if (substream-runtime-periods != CS46XX_FRAGS)
snd_cs46xx_playback_transfer(substream, 0);
@@ -968,8 +968,9 @@
case SNDRV_PCM_TRIGGER_STOP:
case SNDRV_PCM_TRIGGER_SUSPEND:
#ifdef CONFIG_SND_CS46XX_NEW_DSP
- /* mute channel */
- cs46xx_dsp_scb_set_volume (chip,cpcm-pcm_channel-pcm_reader_scb,0,0);
+ /* magic mute channel */
+ snd_cs46xx_poke(chip, (cpcm-pcm_channel-pcm_reader_scb-address +
+ SCBVolumeCtrl) 2, 0x);
if (!cpcm-pcm_channel-unlinked)
cs46xx_dsp_pcm_unlink(chip,cpcm-pcm_channel);
@@ -1063,6 +1064,7 @@
}
#endif
+
static int snd_cs46xx_playback_hw_params(snd_pcm_substream_t * substream,
snd_pcm_hw_params_t * hw_params)
{
@@ -1079,15 +1081,10 @@
down (chip-spos_mutex);
snd_assert (cpcm-pcm_channel != NULL);
-
- /* if IEC958 is opened in AC3 mode dont adjust SRCTask is not
- used so dont adjust sample rate */
- if (cpcm-pcm_channel-pcm_channel_id != DSP_IEC958_CHANNEL ||
- !(chip-dsp_spos_instance-spdif_status_out DSP_SPDIF_STATUS_AC3_MODE)) {
- if (_cs46xx_adjust_sample_rate (chip,cpcm,sample_rate)) {
- up (chip-spos_mutex);
- return -ENXIO;
- }
+
+ if (_cs46xx_adjust_sample_rate (chip,cpcm,sample_rate)) {
+ up (chip-spos_mutex);
+ return -ENXIO;
}
if (cs46xx_dsp_pcm_channel_set_period (chip,cpcm-pcm_channel,period_size *
4)) {
@@ -1886,8 +1883,8 @@
{
cs46xx_t *chip = snd_kcontrol_chip(kcontrol);
- ucontrol-value.integer.value[0] = chip-dsp_spos_instance-dac_volume_right;
- ucontrol-value.integer.value[1] = chip-dsp_spos_instance-dac_volume_left;
+ ucontrol-value.integer.value[0] = chip-dsp_spos_instance-dac_volume_left;
+ ucontrol-value.integer.value[1] = chip-dsp_spos_instance-dac_volume_right;
return 0;
}
@@ -2038,34 +2035,6 @@
return 0;
}
-static int snd_cs46xx_iec958_ac3_mode_get(snd_kcontrol_t *kcontrol,
- snd_ctl_elem_value_t *ucontrol)
-{
- cs46xx_t *chip = snd_kcontrol_chip(kcontrol);
- dsp_spos_instance_t * ins = chip-dsp_spos_instance;
-
- if (!ins-spdif_status_out DSP_SPDIF_STATUS_AC3_MODE)
- ucontrol-value.integer.value[0] = 1;
- else
- ucontrol-value.integer.value[0] = 0;
-
- return 0;
-}
-
-static int
Re: [Alsa-devel] Re: Phase Reversal on Santa Cruz (cs46xx)
On Thursday 21 November 2002 18:09, Benny Sjostrand wrote: Thanks, that explication makes sense. If it was that simple that Santa Cruz where the only card in the world with this problem, but there's the same problem is reported for other cs46xx based card's too. well, how did it work before (0.9.0rc1 worked for sure, I guess I should try to identify the specific version that developed this problem)? Were we using the DSP to invert it previosly, did we lose some Santa Cruz specific bittwiddling (the 'fix' consists of just negating all the levels for one stereo channel). Any guesses? I would like know why the problem does not apear with rc1, but the problem does not apear forme with any release, so I cant reproduce the problem with my equipment, which dont make things easy ... no, that would be annoying indeed :-) The main diference between the old DSP code and the new is that the old DSP is based on a static parameter setup. The new DSP code is a attempt to manage tasks and resources in the DSP dynamically. I dont find any reason to why the DSP would invert one of the channels, in theory the parameter setup made when playing one PCM channel is the same as it is in the old DSP code static loaded (discarding unknown bugs) Finally, the volume could be possible, speculating: if the output sample is the product of volume * sample, and the volume is negative the sample would be negated. The volume in a DSP SCB for each channel is 16 bit value where 0x8000 is the maximum volume and 0x is cero, and lower then 0x8000 dont know. This part now actually differs a little bit from the old static DSP setup. Have you tested my latest patch ?? no, I haven't, since the patch is quite mangled in the www archive and I wasn't subscribed then, I didn't go through th trouble of fixing it up. Is it merged into cvs now, and if not, could you send it my way? I'd be happy to give it a shot. Just as another question, do anyone know if it's possible to use the internal SPDIF connector to feed CD audio into the card instead of the analog input? I can't find anything in the mixer that seems to recieve that input. The cs4630 chip got only one SDPIF input interface, you should see it the mixer with the new DSP code. And if that interface is wired to the internal SPDIF conector without any GPIO story it should just work (however the sounds gets distorcionated (out-of-sync) sometimes with the SPDIF input) ... Hmm, OK. Guess I'll reboot to windows and see if that connection even works there :-P Maybe I just screwed it up. /Benny oh, for anybody using this http://ophelia.student.iastate.edu/~puetzk/arts_phaseinvert-0.7.tgz fixing yet another silly glitch Weijia found. (This is an aRts effect filter which introduces a phase inversion between the channels on purpose, which either fixes or introduces the problem, depending on whether you had it already). --- 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] Re: Phase Reversal on Santa Cruz (cs46xx)
well, the basic premise is simple... the speaker wires have a positive and negative wire, current flows through the coil, and the cone moves one way or the other. If you swap the wires, the cone moves the other way. Inaudible, except that if the two speakers aren't moving the same way, they waves tend to cancel each other out. It affects bass more than treble because the waves are longer and slower, so a) they correleation between the stereo channels is stronger and b) inaccuracies in soundcard timing, etc have less impact. The fact that sound is sensitive to polarity is just basic physics :-) Thanks, that explication makes sense. Now, why in the world the santa cruz would be wired in such a way that software which is fine on other cards would get one channel backwards on it is an excellent question. Espescially when there is older software that worked on all (though not so well, I definitely like having multiple apps accessing it at once). If it was that simple that Santa Cruz where the only card in the world with this problem, but there's the same problem is reported for other cs46xx based card's too. well, how did it work before (0.9.0rc1 worked for sure, I guess I should try to identify the specific version that developed this problem)? Were we using the DSP to invert it previosly, did we lose some Santa Cruz specific bittwiddling (the 'fix' consists of just negating all the levels for one stereo channel). Any guesses? I would like know why the problem does not apear with rc1, but the problem does not apear forme with any release, so I cant reproduce the problem with my equipment, which dont make things easy ... The main diference between the old DSP code and the new is that the old DSP is based on a static parameter setup. The new DSP code is a attempt to manage tasks and resources in the DSP dynamically. I dont find any reason to why the DSP would invert one of the channels, in theory the parameter setup made when playing one PCM channel is the same as it is in the old DSP code static loaded (discarding unknown bugs) Finally, the volume could be possible, speculating: if the output sample is the product of volume * sample, and the volume is negative the sample would be negated. The volume in a DSP SCB for each channel is 16 bit value where 0x8000 is the maximum volume and 0x is cero, and lower then 0x8000 dont know. This part now actually differs a little bit from the old static DSP setup. Have you tested my latest patch ?? Just as another question, do anyone know if it's possible to use the internal SPDIF connector to feed CD audio into the card instead of the analog input? I can't find anything in the mixer that seems to recieve that input. The cs4630 chip got only one SDPIF input interface, you should see it the mixer with the new DSP code. And if that interface is wired to the internal SPDIF conector without any GPIO story it should just work (however the sounds gets distorcionated (out-of-sync) sometimes with the SPDIF input) ... /Benny --- 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] Re: Phase Reversal on Santa Cruz (cs46xx)
On Tuesday 19 November 2002 01:28, you wrote: I get the following error during the 'make' step. I am running kde3.1 rc3 with gcc3.2 err, oops. It only built here because my standard artsmodules.h had stuff in it from when I'd originally just added it to kdemm. My bad. grab http://ophelia.student.iastate.edu/~puetzk/arts_phaseinvert-0.6.tgz, I fixed it. --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: Phase Reversal on Santa Cruz (cs46xx)
Kevin Puetz [EMAIL PROTECTED] writes: Now, why in the world the santa cruz would be wired in such a way that software which is fine on other cards would get one channel backwards on it is an excellent question. Espescially when there is older software that worked on all (though not so well, I definitely like having multiple apps accessing it at once). It's not just the Santa Cruz, though---my IBM T22 laptop has the exact same problem. Mike. --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: Phase Reversal on Santa Cruz (cs46xx)
On Monday 18 November 2002 08:30, Michael Alan Dorman wrote: Kevin Puetz [EMAIL PROTECTED] writes: Now, why in the world the santa cruz would be wired in such a way that software which is fine on other cards would get one channel backwards on it is an excellent question. Espescially when there is older software that worked on all (though not so well, I definitely like having multiple apps accessing it at once). It's not just the Santa Cruz, though---my IBM T22 laptop has the exact same problem. bizzarre... okay, well for any aRts/noatun users who'd like to a) test their card or b) get a temporary workaround, I'll upload my cheesy effect fikter, which will either make your sound much better or much worse :-). http://ophelia.student.iastate.edu/~puetzk/arts_phaseinvert-0.5.tgz standard autoconf/automake setup for kde3, no docs :-) After installing it into your KDE prefix noatun should show Synth_STEREO_PHASEINVERSION as a choice in it's effects config dialog. Mike. --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: Phase Reversal on Santa Cruz (cs46xx)
On Monday 18 November 2002 22:00, Weijia Yang wrote: okay, well for any aRts/noatun users who'd like to a) test their card or b) get a temporary workaround, I'll upload my cheesy effect fikter, which will either make your sound much better or much worse :-). http://ophelia.student.iastate.edu/~puetzk/arts_phaseinvert-0.5.tgz standard autoconf/automake setup for kde3, no docs :-) After installing it into your KDE prefix noatun should show Synth_STEREO_PHASEINVERSION as a choice in it's effects config dialog. Mike. I am not quite sure how to go about compiling this effects plugin. Could you give me a short rundown? Thanks Weijia Yang Alright, standard kde autoconf directions as follows :-P you will need a recent version of autotools (automake, autoconf, autoheader, etc), arts and kdelibs development headers from kde 3 (or 3.1) (ie, you need the -dev pacakges). That should be all... then make -f Makefile.cvs ./configure --prefix=`kde-config --prefix` make make install that should be all, it built here... what problem are you having specifically? --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: Phase Reversal on Santa Cruz (cs46xx)
On Sunday 17 November 2002 23:01, Benny Sjostrand wrote: So... anything that can be done to fix this (I assume so, since it's a new problem since older alsa), or do I have to cut my speaker wires apart? :-P I'm still a newbie to the audio world, but just wondering, why design a audio equipment that behaves like this ?? (When you run out of ideas howto fix something let's try to move it into a HW bug instead -;) ) well, the basic premise is simple... the speaker wires have a positive and negative wire, current flows through the coil, and the cone moves one way or the other. If you swap the wires, the cone moves the other way. Inaudible, except that if the two speakers aren't moving the same way, they waves tend to cancel each other out. It affects bass more than treble because the waves are longer and slower, so a) they correleation between the stereo channels is stronger and b) inaccuracies in soundcard timing, etc have less impact. The fact that sound is sensitive to polarity is just basic physics :-) Now, why in the world the santa cruz would be wired in such a way that software which is fine on other cards would get one channel backwards on it is an excellent question. Espescially when there is older software that worked on all (though not so well, I definitely like having multiple apps accessing it at once). Still hopfully alsa gets fixed and I can throw away the effect plugin :-) One alternative solution would be program the DSP to do the job instead and you will save CPU time. (Yet another thing that I dont known howto do -:( ) well, how did it work before (0.9.0rc1 worked for sure, I guess I should try to identify the specific version that developed this problem)? Were we using the DSP to invert it previosly, did we lose some Santa Cruz specific bittwiddling (the 'fix' consists of just negating all the levels for one stereo channel). Any guesses? /Benny PS. being out for traveling some days (wont respond any mail for a while ...) Just as another question, do anyone know if it's possible to use the internal SPDIF connector to feed CD audio into the card instead of the analog input? I can't find anything in the mixer that seems to recieve that input. --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
