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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-devel
