Re: Audigy SPDIF Output Sample Rate

Re: Audigy SPDIF Output Sample Rate

[Lee Revell]

[-- Attachment #1: Type: text/plain, Size: 1996 bytes --]

On Sun, 2005-02-20 at 01:28 -0500, Brian L Scipioni wrote:
> I'm using yesterday's CVS.
> 
> The new alsamixer control "Audigy SPDIF Output Sample Rate" for the
> emu10k1 toggles the sample rate among 44100, 48000 and 96000.  I believe
> the mapping here is wrong (or at least the 3 rate labels are reversed). 
> My 5.1 receiver will accept 441000, 48000 or 96000 from SPDIF.  When it
> receives a 96KHz, signal it will indicate that with "96 k" printed out
> on the receiver front panel LEDs.  It does that when alsamixer selects
> 44100 and NOT 48000 or 96000.  So when alsamixer displays 44100, it
> appears 96000 is actually being output.
> 

Thanks.  Please try the attached patch.

Does your receiver tell you if it's receiving 48000 or 44100?  If so
please check that those are also correct.

So, have you tested that 96KHz SPDIF playback sounds OK?  None of the
alsa developers seem to have a 96KHz capable receiver (unless someone
want to give me one ;-)) so this is all untested so far.

> Also some new behavior with the latest CVS:
> When monitoring Aux2 in, the sound is badly distorted until the "Audigy
> SPDIF Output Sample Rate" switch is toggled back and forth among the
> rates.  After a little rate switching, the sound becomes fine.

This is probably related to this cryptic comment from some Creative
engineer:

298             if (emu->revision == 4) { /* audigy2 */
299                     /* Unmute Analog now.  Set GPO6 to 1 for Apollo.
300                      * This has to be done after init ALice3 I2SOut beyond 48KHz.
301                      * So, sequence is important. */
302                     outl(inl(emu->port + A_IOCFG) | 0x0040, emu->port + A_IOCFG);

We have no idea what "Alice3" and "Apollo" are, though we have some good
guesses ;-)

I'll see if I can fix this.  The comment implies that in order to set
96KHz mode, we may have to mute and unmute analog around the samplerate
register setting.  So instead of noise you would get a brief silence.

Lee

[-- Attachment #2: emu10k1-96-fix.patch --]
[-- Type: text/x-patch, Size: 859 bytes --]

Index: alsa-postv12/alsa-kernel/include/emu10k1.h
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/include/emu10k1.h,v
retrieving revision 1.57
diff -u -r1.57 emu10k1.h
--- alsa-postv12/alsa-kernel/include/emu10k1.h	17 Feb 2005 14:48:07 -0000	1.57
+++ alsa-postv12/alsa-kernel/include/emu10k1.h	25 Feb 2005 17:10:04 -0000
@@ -764,9 +764,9 @@
 
 #define A_SPDIF_SAMPLERATE	0x76		/* Set the sample rate of SPDIF output		*/
 #define A_SPDIF_RATE_MASK	0x000000c0
-#define A_SPDIF_48000		0x00000000
-#define A_SPDIF_44100		0x00000040
-#define A_SPDIF_96000		0x00000080
+#define A_SPDIF_48000		0x00000080
+#define A_SPDIF_44100		0x00000000
+#define A_SPDIF_96000		0x00000040
 
 /* 0x77,0x78,0x79 "something i2s-related" - default to 0x01080000 on my audigy 2 ZS --rlrevell	*/
 /* 0x7a, 0x7b - lookup tables */

Re: Audigy SPDIF Output Sample Rate

[Lee Revell]

On Fri, 2005-02-25 at 22:44 +0100, The Orqwith Vagrant wrote:
> On Fri, 2005-02-25 at 12:17 -0500, Lee Revell wrote: 
> > On Sun, 2005-02-20 at 01:28 -0500, Brian L Scipioni wrote:
> > > I'm using yesterday's CVS.
> > > 
> > > The new alsamixer control "Audigy SPDIF Output Sample Rate" for the
> > > emu10k1 toggles the sample rate among 44100, 48000 and 96000.  I believe
> > > the mapping here is wrong (or at least the 3 rate labels are reversed). 
> > > My 5.1 receiver will accept 441000, 48000 or 96000 from SPDIF.  When it
> > > receives a 96KHz, signal it will indicate that with "96 k" printed out
> > > on the receiver front panel LEDs.  It does that when alsamixer selects
> > > 44100 and NOT 48000 or 96000.  So when alsamixer displays 44100, it
> > > appears 96000 is actually being output.
> > > 
> > 
> > Thanks.  Please try the attached patch.
> > 
> > Does your receiver tell you if it's receiving 48000 or 44100?  If so
> > please check that those are also correct.
> > 
> > So, have you tested that 96KHz SPDIF playback sounds OK?  None of the
> > alsa developers seem to have a 96KHz capable receiver (unless someone
> > want to give me one ;-)) so this is all untested so far.
> > 
> > > Also some new behavior with the latest CVS:
> > > When monitoring Aux2 in, the sound is badly distorted until the "Audigy
> > > SPDIF Output Sample Rate" switch is toggled back and forth among the
> > > rates.  After a little rate switching, the sound becomes fine.
> > 
> > This is probably related to this cryptic comment from some Creative
> > engineer:
> > 
> > 298             if (emu->revision == 4) { /* audigy2 */
> > 299                     /* Unmute Analog now.  Set GPO6 to 1 for Apollo.
> > 300                      * This has to be done after init ALice3 I2SOut beyond 48KHz.
> > 301                      * So, sequence is important. */
> > 302                     outl(inl(emu->port + A_IOCFG) | 0x0040, emu->port + A_IOCFG);
> > 
> > We have no idea what "Alice3" and "Apollo" are, though we have some good
> > guesses ;-)
> > 
> > I'll see if I can fix this.  The comment implies that in order to set
> > 96KHz mode, we may have to mute and unmute analog around the samplerate
> > register setting.  So instead of noise you would get a brief silence.
> > 
> > Lee
> 
> As someone who does have a 96 Khz capable reciever, I thought I might
> add my own comments tho this. The 96khz setting works perfect, sounds
> perfect with this patch; however, 48 & 44.1 are reversed now. Trying to
> play 48khz samples when the setting is 44.1 causes ugly scratchy
> distortion, but oddly, only on the right channel. Using the spdif raw
> PCM device, which reverses left and right channels of a stereo file,
> still has the distortion on the right channel.

OK I'll post a new patch.

> No luck with ac3 at any sample rate, but ac3 passthrough has never
> worked for me, and I have tried basically everything suggested on this
> mailing list to others with similar problems. The reason I'm always
> quick to test any patch/change that touches emu10k1 SPDIF is because I'm
> always hopeful it will somehow also solve my AC3-deficiency. No luck
> with _that_ so far. Oh well...
> 

That's strange.  It should work.  I guess you made sure to enable the
"IEC958 Optical Raw" switch, and the "Audigy Analog/Digital Mode"?

There was someone else who could not get it to work no matter what and
swapping the cable fixed it.

Anyway, that's weird.

> One thing tho: iecset still lists the spdif output rate as 48khz when
> it's set to 96khz, even though the reciever does say it's getting 96khz.
> Furthermore, trying to use "iecset rate 96000" causes iecset to report
> 44.1khz... but no change on the reciever, it still says 96khz if it's
> set that way in the alsa mixer, Should this be the case?
> Another - wouldn't in fact iecset be what you should use to change this
> setting, rather than have a mixer element for it? I saw a change like
> that was done in another driver recently, so perhaps that'd be a good
> idea for emu10k1 as well, if only for the sake of consistency?
> 

The reason I made it a separate control is that 96KHz mode is not set by
the standard SPDIF status bits.  There is a separate register for it.

Maybe someone on alsa-devel can explain the relationship between this
control and iecset.  I really have no idea.

> Notes: My card is an Audigy2 Platinum, my amp is a Denon AVR-3803, and
> I'm using the optical spdif connector on the audigy drive to connect
> them.
> 

Can someone else with the same hardware can confirm or deny that they
also have the AC3 problem?  Also, did you open a bug report?  Please
check for an existing one first.

Lee



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: [Alsa-user] Audigy SPDIF Output Sample Rate

[James Courtier-Dutton]

Lee Revell wrote:
> On Fri, 2005-02-25 at 22:44 +0100, The Orqwith Vagrant wrote:
> 
>>On Fri, 2005-02-25 at 12:17 -0500, Lee Revell wrote: 
>>
>>>On Sun, 2005-02-20 at 01:28 -0500, Brian L Scipioni wrote:
>>>
>>>>I'm using yesterday's CVS.
>>>>
>>>>The new alsamixer control "Audigy SPDIF Output Sample Rate" for the
>>>>emu10k1 toggles the sample rate among 44100, 48000 and 96000.  I believe
>>>>the mapping here is wrong (or at least the 3 rate labels are reversed). 
>>>>My 5.1 receiver will accept 441000, 48000 or 96000 from SPDIF.  When it
>>>>receives a 96KHz, signal it will indicate that with "96 k" printed out
>>>>on the receiver front panel LEDs.  It does that when alsamixer selects
>>>>44100 and NOT 48000 or 96000.  So when alsamixer displays 44100, it
>>>>appears 96000 is actually being output.
>>>>
>>>
>>>Thanks.  Please try the attached patch.
>>>
>>>Does your receiver tell you if it's receiving 48000 or 44100?  If so
>>>please check that those are also correct.
>>>
>>>So, have you tested that 96KHz SPDIF playback sounds OK?  None of the
>>>alsa developers seem to have a 96KHz capable receiver (unless someone
>>>want to give me one ;-)) so this is all untested so far.
>>>
>>>
>>>>Also some new behavior with the latest CVS:
>>>>When monitoring Aux2 in, the sound is badly distorted until the "Audigy
>>>>SPDIF Output Sample Rate" switch is toggled back and forth among the
>>>>rates.  After a little rate switching, the sound becomes fine.
>>>
>>>This is probably related to this cryptic comment from some Creative
>>>engineer:
>>>
>>>298             if (emu->revision == 4) { /* audigy2 */
>>>299                     /* Unmute Analog now.  Set GPO6 to 1 for Apollo.
>>>300                      * This has to be done after init ALice3 I2SOut beyond 48KHz.
>>>301                      * So, sequence is important. */
>>>302                     outl(inl(emu->port + A_IOCFG) | 0x0040, emu->port + A_IOCFG);
>>>
>>>We have no idea what "Alice3" and "Apollo" are, though we have some good
>>>guesses ;-)
>>>
>>>I'll see if I can fix this.  The comment implies that in order to set
>>>96KHz mode, we may have to mute and unmute analog around the samplerate
>>>register setting.  So instead of noise you would get a brief silence.
>>>
>>>Lee
>>
>>As someone who does have a 96 Khz capable reciever, I thought I might
>>add my own comments tho this. The 96khz setting works perfect, sounds
>>perfect with this patch; however, 48 & 44.1 are reversed now. Trying to
>>play 48khz samples when the setting is 44.1 causes ugly scratchy
>>distortion, but oddly, only on the right channel. Using the spdif raw
>>PCM device, which reverses left and right channels of a stereo file,
>>still has the distortion on the right channel.
> 
> 
> OK I'll post a new patch.
> 
> 
>>No luck with ac3 at any sample rate, but ac3 passthrough has never
>>worked for me, and I have tried basically everything suggested on this
>>mailing list to others with similar problems. The reason I'm always
>>quick to test any patch/change that touches emu10k1 SPDIF is because I'm
>>always hopeful it will somehow also solve my AC3-deficiency. No luck
>>with _that_ so far. Oh well...
>>
> 
> 
> That's strange.  It should work.  I guess you made sure to enable the
> "IEC958 Optical Raw" switch, and the "Audigy Analog/Digital Mode"?
> 
> There was someone else who could not get it to work no matter what and
> swapping the cable fixed it.
> 
> Anyway, that's weird.
> 
> 
>>One thing tho: iecset still lists the spdif output rate as 48khz when
>>it's set to 96khz, even though the reciever does say it's getting 96khz.
>>Furthermore, trying to use "iecset rate 96000" causes iecset to report
>>44.1khz... but no change on the reciever, it still says 96khz if it's
>>set that way in the alsa mixer, Should this be the case?
>>Another - wouldn't in fact iecset be what you should use to change this
>>setting, rather than have a mixer element for it? I saw a change like
>>that was done in another driver recently, so perhaps that'd be a good
>>idea for emu10k1 as well, if only for the sake of consistency?
>>
> 
> 
> The reason I made it a separate control is that 96KHz mode is not set by
> the standard SPDIF status bits.  There is a separate register for it.
> 
> Maybe someone on alsa-devel can explain the relationship between this
> control and iecset.  I really have no idea.
> 
> 
>>Notes: My card is an Audigy2 Platinum, my amp is a Denon AVR-3803, and
>>I'm using the optical spdif connector on the audigy drive to connect
>>them.
>>
> 
> 
> Can someone else with the same hardware can confirm or deny that they
> also have the AC3 problem?  Also, did you open a bug report?  Please
> check for an existing one first.
> 
> Lee
> 

I just thought I would add an explanation of what is happening with 
these settings:

CPU -> EMU10K2 sample rate converters -> EMU10K2 DSP at 48khz -> P16V 
chip -> P16V sample rate converter -> SPDIF out.

So, setting the SPDIF out to different speeds will change the output 
rate, but it will still be 48khz at the DSP. It does not bypass the DSP 
at all.

Although you think you are playing with a register in the EMU10K2 chip, 
you are in fact modifying a register in the P16V when setting the output 
sample rate. The P16V chip listens to any changes you make to EMU10K2 
registers, and uses certain registers of the EMU10K2 space to configure 
itself.

One advantage of the investigation work you are doing, is that although 
I have signed NDAs with Creative, they have not told me anything about 
the EMU10K2, so I don't know what the EMU10K2 registers need to be set 
to for 96Khz SPDIF out.

Once my P16V code is integrated into the EMU10K2 alsa driver, you will 
get proper passthru for 44.1, 48 and 96 khz SPDIF rates.

My current test code for the integration is not compatible with the 
latest multichannel code that has just gone into the CVS, so do not try 
it yet.

Cheers

James


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: [Alsa-user] Audigy SPDIF Output Sample Rate

[Lee Revell]

On Fri, 2005-02-25 at 22:22 +0000, James Courtier-Dutton wrote:
> Lee Revell wrote:
> > On Fri, 2005-02-25 at 22:44 +0100, The Orqwith Vagrant wrote:
> > 
> >>On Fri, 2005-02-25 at 12:17 -0500, Lee Revell wrote: 
> >>
> >>>On Sun, 2005-02-20 at 01:28 -0500, Brian L Scipioni wrote:
> >>>
> >>>>I'm using yesterday's CVS.
> >>>>
> >>>>The new alsamixer control "Audigy SPDIF Output Sample Rate" for the
> >>>>emu10k1 toggles the sample rate among 44100, 48000 and 96000.  I believe
> >>>>the mapping here is wrong (or at least the 3 rate labels are reversed). 
> >>>>My 5.1 receiver will accept 441000, 48000 or 96000 from SPDIF.  When it
> >>>>receives a 96KHz, signal it will indicate that with "96 k" printed out
> >>>>on the receiver front panel LEDs.  It does that when alsamixer selects
> >>>>44100 and NOT 48000 or 96000.  So when alsamixer displays 44100, it
> >>>>appears 96000 is actually being output.
> >>>>
> >>>
> >>>Thanks.  Please try the attached patch.
> >>>
> >>>Does your receiver tell you if it's receiving 48000 or 44100?  If so
> >>>please check that those are also correct.
> >>>
> >>>So, have you tested that 96KHz SPDIF playback sounds OK?  None of the
> >>>alsa developers seem to have a 96KHz capable receiver (unless someone
> >>>want to give me one ;-)) so this is all untested so far.
> >>>
> >>>
> >>>>Also some new behavior with the latest CVS:
> >>>>When monitoring Aux2 in, the sound is badly distorted until the "Audigy
> >>>>SPDIF Output Sample Rate" switch is toggled back and forth among the
> >>>>rates.  After a little rate switching, the sound becomes fine.
> >>>
> >>>This is probably related to this cryptic comment from some Creative
> >>>engineer:
> >>>
> >>>298             if (emu->revision == 4) { /* audigy2 */
> >>>299                     /* Unmute Analog now.  Set GPO6 to 1 for Apollo.
> >>>300                      * This has to be done after init ALice3 I2SOut beyond 48KHz.
> >>>301                      * So, sequence is important. */
> >>>302                     outl(inl(emu->port + A_IOCFG) | 0x0040, emu->port + A_IOCFG);
> >>>
> >>>We have no idea what "Alice3" and "Apollo" are, though we have some good
> >>>guesses ;-)
> >>>
> >>>I'll see if I can fix this.  The comment implies that in order to set
> >>>96KHz mode, we may have to mute and unmute analog around the samplerate
> >>>register setting.  So instead of noise you would get a brief silence.
> >>>
> >>>Lee
> >>
> >>As someone who does have a 96 Khz capable reciever, I thought I might
> >>add my own comments tho this. The 96khz setting works perfect, sounds
> >>perfect with this patch; however, 48 & 44.1 are reversed now. Trying to
> >>play 48khz samples when the setting is 44.1 causes ugly scratchy
> >>distortion, but oddly, only on the right channel. Using the spdif raw
> >>PCM device, which reverses left and right channels of a stereo file,
> >>still has the distortion on the right channel.
> > 
> > 
> > OK I'll post a new patch.
> > 
> > 
> >>No luck with ac3 at any sample rate, but ac3 passthrough has never
> >>worked for me, and I have tried basically everything suggested on this
> >>mailing list to others with similar problems. The reason I'm always
> >>quick to test any patch/change that touches emu10k1 SPDIF is because I'm
> >>always hopeful it will somehow also solve my AC3-deficiency. No luck
> >>with _that_ so far. Oh well...
> >>
> > 
> > 
> > That's strange.  It should work.  I guess you made sure to enable the
> > "IEC958 Optical Raw" switch, and the "Audigy Analog/Digital Mode"?
> > 
> > There was someone else who could not get it to work no matter what and
> > swapping the cable fixed it.
> > 
> > Anyway, that's weird.
> > 
> > 
> >>One thing tho: iecset still lists the spdif output rate as 48khz when
> >>it's set to 96khz, even though the reciever does say it's getting 96khz.
> >>Furthermore, trying to use "iecset rate 96000" causes iecset to report
> >>44.1khz... but no change on the reciever, it still says 96khz if it's
> >>set that way in the alsa mixer, Should this be the case?
> >>Another - wouldn't in fact iecset be what you should use to change this
> >>setting, rather than have a mixer element for it? I saw a change like
> >>that was done in another driver recently, so perhaps that'd be a good
> >>idea for emu10k1 as well, if only for the sake of consistency?
> >>
> > 
> > 
> > The reason I made it a separate control is that 96KHz mode is not set by
> > the standard SPDIF status bits.  There is a separate register for it.
> > 
> > Maybe someone on alsa-devel can explain the relationship between this
> > control and iecset.  I really have no idea.
> > 
> > 
> >>Notes: My card is an Audigy2 Platinum, my amp is a Denon AVR-3803, and
> >>I'm using the optical spdif connector on the audigy drive to connect
> >>them.
> >>
> > 
> > 
> > Can someone else with the same hardware can confirm or deny that they
> > also have the AC3 problem?  Also, did you open a bug report?  Please
> > check for an existing one first.
> > 
> > Lee
> > 
> 
> I just thought I would add an explanation of what is happening with 
> these settings:
> 
> CPU -> EMU10K2 sample rate converters -> EMU10K2 DSP at 48khz -> P16V 
> chip -> P16V sample rate converter -> SPDIF out.
> 
> So, setting the SPDIF out to different speeds will change the output 
> rate, but it will still be 48khz at the DSP. It does not bypass the DSP 
> at all.
> 
> Although you think you are playing with a register in the EMU10K2 chip, 
> you are in fact modifying a register in the P16V when setting the output 
> sample rate. The P16V chip listens to any changes you make to EMU10K2 
> registers, and uses certain registers of the EMU10K2 space to configure 
> itself.
> 
> One advantage of the investigation work you are doing, is that although 
> I have signed NDAs with Creative, they have not told me anything about 
> the EMU10K2, so I don't know what the EMU10K2 registers need to be set 
> to for 96Khz SPDIF out.
> 
> Once my P16V code is integrated into the EMU10K2 alsa driver, you will 
> get proper passthru for 44.1, 48 and 96 khz SPDIF rates.
> 
> My current test code for the integration is not compatible with the 
> latest multichannel code that has just gone into the CVS, so do not try 
> it yet.

OK, that makes things clearer.  So the 96KHz output Vagrant is hearing
has been internally resampled to 48KHz, but once we have proper P16V
support it will be "real" 96KHz.

Do you think we should disable this control until the your P16V patch
goes in?  There are no real conflicts with the P16V and multichannel
patches, it looks like it's just a matter of regenerating it.

Lee





-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: [Alsa-user] Audigy SPDIF Output Sample Rate

[Lee Revell]

[-- Attachment #1: Type: text/plain, Size: 710 bytes --]

On Fri, 2005-02-25 at 16:58 -0500, Lee Revell wrote:
> On Fri, 2005-02-25 at 22:44 +0100, The Orqwith Vagrant wrote:
> > As someone who does have a 96 Khz capable reciever, I thought I might
> > add my own comments tho this. The 96khz setting works perfect, sounds
> > perfect with this patch; however, 48 & 44.1 are reversed now. Trying to
> > play 48khz samples when the setting is 44.1 causes ugly scratchy
> > distortion, but oddly, only on the right channel. Using the spdif raw
> > PCM device, which reverses left and right channels of a stereo file,
> > still has the distortion on the right channel.
> 
> OK I'll post a new patch.
> 

Please try the attached patch (revert the last patch first).

Lee


[-- Attachment #2: emu10k1-96-fix2.patch --]
[-- Type: text/x-patch, Size: 822 bytes --]

Index: alsa-postv12/alsa-kernel/include/emu10k1.h
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/include/emu10k1.h,v
retrieving revision 1.57
diff -u -r1.57 emu10k1.h
--- alsa-postv12/alsa-kernel/include/emu10k1.h	17 Feb 2005 14:48:07 -0000	1.57
+++ alsa-postv12/alsa-kernel/include/emu10k1.h	25 Feb 2005 22:38:24 -0000
@@ -765,8 +765,8 @@
 #define A_SPDIF_SAMPLERATE	0x76		/* Set the sample rate of SPDIF output		*/
 #define A_SPDIF_RATE_MASK	0x000000c0
 #define A_SPDIF_48000		0x00000000
-#define A_SPDIF_44100		0x00000040
-#define A_SPDIF_96000		0x00000080
+#define A_SPDIF_44100		0x00000080
+#define A_SPDIF_96000		0x00000040
 
 /* 0x77,0x78,0x79 "something i2s-related" - default to 0x01080000 on my audigy 2 ZS --rlrevell	*/
 /* 0x7a, 0x7b - lookup tables */

Re: [Alsa-devel] Re: Audigy SPDIF Output Sample Rate

[James Courtier-Dutton]

Lee Revell wrote:
> 
> 
> OK, that makes things clearer.  So the 96KHz output Vagrant is hearing
> has been internally resampled to 48KHz, but once we have proper P16V
> support it will be "real" 96KHz.
> 
> Do you think we should disable this control until the your P16V patch
> goes in?  There are no real conflicts with the P16V and multichannel
> patches, it looks like it's just a matter of regenerating it.
> 

In my p16v.c code there is the line:

#define P16V_OFFSET 0x03 /* FIXME: The number of the first P16V device. */

So this is obviously not going to work with the multichannel patch, 
because it uses device 3.

The fix is relatively simple, but I will need to implement mixer 
controls as well before my code is ready to commit.
I will get round to is some time, but not this weekend.

James


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Audigy SPDIF Output Sample Rate

[Lee Revell]

[-- Attachment #1: Type: text/plain, Size: 1312 bytes --]

On Fri, 2005-02-25 at 23:55 +0100, The Orqwith Vagrant wrote:
> On Fri, 2005-02-25 at 17:39 -0500, Lee Revell wrote:
> > On Fri, 2005-02-25 at 16:58 -0500, Lee Revell wrote:
> > > On Fri, 2005-02-25 at 22:44 +0100, The Orqwith Vagrant wrote:
> > > > As someone who does have a 96 Khz capable reciever, I thought I might
> > > > add my own comments tho this. The 96khz setting works perfect, sounds
> > > > perfect with this patch; however, 48 & 44.1 are reversed now. Trying to
> > > > play 48khz samples when the setting is 44.1 causes ugly scratchy
> > > > distortion, but oddly, only on the right channel. Using the spdif raw
> > > > PCM device, which reverses left and right channels of a stereo file,
> > > > still has the distortion on the right channel.
> > > 
> > > OK I'll post a new patch.
> > > 
> > 
> > Please try the attached patch (revert the last patch first).
> > 
> > Lee
> > 
> 
> Done. Sample rates are correct with this patch. The distortion when
> playing 48khz samples with 44.1khz spdif rate is also gone.
> 

OK, great!  That means that both the OSS and the ALSA driver had it
wrong.

ALSA maintainers, please apply this patch to CVS.  Here it is again for
convenience.

Summary: Fix the Audigy SPDIF sample rate register definitions

Signed-Off-By: Lee Revell <rlrevell@joe-job.com>
 


[-- Attachment #2: emu10k1-96-fix2.patch --]
[-- Type: text/x-patch, Size: 822 bytes --]

Index: alsa-postv12/alsa-kernel/include/emu10k1.h
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/include/emu10k1.h,v
retrieving revision 1.57
diff -u -r1.57 emu10k1.h
--- alsa-postv12/alsa-kernel/include/emu10k1.h	17 Feb 2005 14:48:07 -0000	1.57
+++ alsa-postv12/alsa-kernel/include/emu10k1.h	25 Feb 2005 22:38:24 -0000
@@ -765,8 +765,8 @@
 #define A_SPDIF_SAMPLERATE	0x76		/* Set the sample rate of SPDIF output		*/
 #define A_SPDIF_RATE_MASK	0x000000c0
 #define A_SPDIF_48000		0x00000000
-#define A_SPDIF_44100		0x00000040
-#define A_SPDIF_96000		0x00000080
+#define A_SPDIF_44100		0x00000080
+#define A_SPDIF_96000		0x00000040
 
 /* 0x77,0x78,0x79 "something i2s-related" - default to 0x01080000 on my audigy 2 ZS --rlrevell	*/
 /* 0x7a, 0x7b - lookup tables */

Re: Audigy SPDIF Output Sample Rate

[Brian L Scipioni]

> 
> Can someone else with the same hardware can confirm or deny that they
> also have the AC3 problem?  Also, did you open a bug report?  Please
> check for an existing one first.
> 
> Lee
> 

See my previous posts.  I've reported this problem some months ago.




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: [Alsa-devel] Re: Audigy SPDIF Output Sample Rate

[Brian L Scipioni]

Lee,

> Please try the attached patch (revert the last patch first).

I tried this patch (emu10k1-96-fix2.patch) against the Saturday, 2/26,
CVS and I still get 41000 alsamixer = 96000 IEC958 out.

I never tried the previous patch, so did not revert it.  Do I have the
right versions of CVS+patch?

thanks,
brian



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: [Alsa-user] Audigy SPDIF Output Sample Rate

[The Orqwith Vagrant]

On Sun, 2005-02-27 at 05:17 -0500, Brian L Scipioni wrote:
> Lee,
> 
> > Please try the attached patch (revert the last patch first).
> 
> I tried this patch (emu10k1-96-fix2.patch) against the Saturday, 2/26,
> CVS and I still get 41000 alsamixer = 96000 IEC958 out.
> 
> I never tried the previous patch, so did not revert it.  Do I have the
> right versions of CVS+patch?
> 
> thanks,
> brian
> 

Yes, that's the cvs version i applied the patch against, and it
definitely works right for me. Are you positive you got the old driver
completely unloaded before you tried loading the new one? Or maybe you
forgot to do a "make install" after the ./cvscompile? I've ended up
scratching my head after forgotting that step a couple of times myself.
Happens to the best of us. :)



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click