RME 9632

RME 9632

[Remy Bruno]

Hello,

I'm having a strange problem with an RME HDSP 9632 card I recently bought. I've
contacted RME, but would like to know if somebody here is having the same
problem, or if there is a known issue about this (and if possible, a
workaround).

Start of the story: a couple of monthes ago (let's say about one year, but I'm
not sure of the time-scale), I got a RME HDSP 9632. Alsa driver was working
perfectly, I got the 12 I/O (16 with the additionnal add-on cards), the mixer
matrix worked as expected (mixer params = src,dest,32768 with src=dest+16 for
sending playback channels to audio outputs). After an hardware problem with the
card (I plugged the analog add-on card while it was running, which burned the
card!), I had to get a new one. I didn't manage to get this new card work, so I
suspected a specific problem with this new card. More recently (one week ago),
I needed to use an RME9632, so I got a new one, and I'm having about the same
problem than with the 2nd one:
- card does not work in master. Everything is as if it ran at 24kHz (sound
  plays slowly), even if the card pretends to run at the desired sample rate
  (say 44.1 or 48kHz). So master mode is unusable.
  Master worked with the 1st card.
- in slave, it seems to be more or less OK, but the matrix behavior is
  extremely weird. For sending playback channels 9,10,11,12 on outputs
  9,10,11,12 (SPDIF & analog), I need to put the value 32768 in the following
  coefficients: (62, 4), (1, 6), (24, 6), (15, 7)
  With the first (now dead) card, I used the normal following matrix
  coefficients: (24,8) (25,9), (26, 10), (27, 11)

Any idea?

Thanks

Remy


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: RME 9632 - Problem half solved

[Remy Bruno]

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

Hello,

I solved the matrix problem. In fact, it was quite obvious by looking at the
hdsp driver code. The 9632 card was considered as a 9652 regarding the matrix,
and so the offsets in the matrix were wrong. See the attached patch. I think
the "switch()" statement should be replaced by an "if (hdsp->firmware_rev >=
0x96)", which would allow the next firmwares of the hdsp9632 to be considered
as hdsp9632 and not as 9652.

For the frequency problem, I got an answer from RME which explains that another
register needs to be set (together with the freq0, 1, 2 bits of the control
register). This register is the "DDS" register. Here is how it should be
computed:
UINT64 CalcDDSValue(UINT64 rate)
{
        if (rate >= 112000)
                rate /= 4;
        else if (rate >= 56000)
                rate /= 2;

        return 104857600000000 / rate;
}
MemBase[FREQ_REG] = (ULONG)CalcDDSValue(new_rate)

Any ideas of what the offset of this register is? If not, I will ask him. BTW,
this register exists only for the 9632 and not for the 9652.

Regards,

Remy


On Tuesday 03 October at 12:37, Remy Bruno wrote:
> Hello,
> 
> I'm having a strange problem with an RME HDSP 9632 card I recently bought. I've
> contacted RME, but would like to know if somebody here is having the same
> problem, or if there is a known issue about this (and if possible, a
> workaround).
> 
> Start of the story: a couple of monthes ago (let's say about one year, but I'm
> not sure of the time-scale), I got a RME HDSP 9632. Alsa driver was working
> perfectly, I got the 12 I/O (16 with the additionnal add-on cards), the mixer
> matrix worked as expected (mixer params = src,dest,32768 with src=dest+16 for
> sending playback channels to audio outputs). After an hardware problem with the
> card (I plugged the analog add-on card while it was running, which burned the
> card!), I had to get a new one. I didn't manage to get this new card work, so I
> suspected a specific problem with this new card. More recently (one week ago),
> I needed to use an RME9632, so I got a new one, and I'm having about the same
> problem than with the 2nd one:
> - card does not work in master. Everything is as if it ran at 24kHz (sound
>   plays slowly), even if the card pretends to run at the desired sample rate
>   (say 44.1 or 48kHz). So master mode is unusable.
>   Master worked with the 1st card.
> - in slave, it seems to be more or less OK, but the matrix behavior is
>   extremely weird. For sending playback channels 9,10,11,12 on outputs
>   9,10,11,12 (SPDIF & analog), I need to put the value 32768 in the following
>   coefficients: (62, 4), (1, 6), (24, 6), (15, 7)
>   With the first (now dead) card, I used the normal following matrix
>   coefficients: (24,8) (25,9), (26, 10), (27, 11)
> 
> Any idea?
> 
> Thanks
> 
> Remy
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel

[-- Attachment #2: hdsp.c.diff --]
[-- Type: text/plain, Size: 427 bytes --]

--- hdsp.c.org	2006-09-29 13:40:37.000000000 +0200
+++ hdsp.c	2006-10-06 15:26:44.000000000 +0200
@@ -598,6 +598,7 @@
 		return (64 * out) + (32 + (in));
 	case 0x96:
 	case 0x97:
+	case 0x98:
 		return (32 * out) + (16 + (in));
 	default:
 		return (52 * out) + (26 + (in));
@@ -611,6 +612,7 @@
 		return (64 * out) + in;
 	case 0x96:
 	case 0x97:
+	case 0x98:
 		return (32 * out) + in;
 	default:
 		return (52 * out) + in;

[-- Attachment #3: Type: text/plain, Size: 348 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #4: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: RME 9632 - Problem half solved

[Takashi Iwai]

At Fri, 6 Oct 2006 15:53:55 +0200,
Remy Bruno wrote:
> 
> Hello,
> 
> I solved the matrix problem. In fact, it was quite obvious by looking at the
> hdsp driver code. The 9632 card was considered as a 9652 regarding the matrix,
> and so the offsets in the matrix were wrong. See the attached patch. I think
> the "switch()" statement should be replaced by an "if (hdsp->firmware_rev >=
> 0x96)", which would allow the next firmwares of the hdsp9632 to be considered
> as hdsp9632 and not as 9652.

Could you give a proper changelog text and a signed-off-by line to
merge your patch into ALSA tree?

> 
> For the frequency problem, I got an answer from RME which explains that another
> register needs to be set (together with the freq0, 1, 2 bits of the control
> register). This register is the "DDS" register. Here is how it should be
> computed:
> UINT64 CalcDDSValue(UINT64 rate)
> {
>         if (rate >= 112000)
>                 rate /= 4;
>         else if (rate >= 56000)
>                 rate /= 2;
> 
>         return 104857600000000 / rate;
> }
> MemBase[FREQ_REG] = (ULONG)CalcDDSValue(new_rate)
> 
> Any ideas of what the offset of this register is? If not, I will ask him. BTW,
> this register exists only for the 9632 and not for the 9652.

Hm, the numerator is pretty big, it's 0x100000 * 10^7.
A clock with fixed point?

Anyway, remember that you cannot use 64bit division in the linux
kernel code as it is.  You can use a macro div64_32 defined in pcm.h,
though.


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: RME 9632 - Problem half solved

[Remy Bruno]

On Friday 06 October at 19:12, Takashi Iwai wrote:
> Could you give a proper changelog text and a signed-off-by line to
> merge your patch into ALSA tree?

Changelog:
hdsp: support for mixer matrix of RME9632 rev 152

Signed-off-by: Remy Bruno <remy.bruno@trinnov.com>

> 
> > 
> > For the frequency problem, I got an answer from RME which explains that another
> > register needs to be set (together with the freq0, 1, 2 bits of the control
> > register). This register is the "DDS" register. Here is how it should be
> > computed:
> > UINT64 CalcDDSValue(UINT64 rate)
> > {
> >         if (rate >= 112000)
> >                 rate /= 4;
> >         else if (rate >= 56000)
> >                 rate /= 2;
> > 
> >         return 104857600000000 / rate;
> > }
> > MemBase[FREQ_REG] = (ULONG)CalcDDSValue(new_rate)
> > 
> > Any ideas of what the offset of this register is? If not, I will ask him. BTW,
> > this register exists only for the 9632 and not for the 9652.
> 
> Hm, the numerator is pretty big, it's 0x100000 * 10^7.
> A clock with fixed point?

Yes, that's weird. That's what they told me. I'll investigate this.

> 
> Anyway, remember that you cannot use 64bit division in the linux
> kernel code as it is.  You can use a macro div64_32 defined in pcm.h,
> though.

OK

Remy

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV