[alsa-devel] HDSPM: Wrong samplerate on PCI cards

[Adrian Knoth]

On 04/18/2012 04:59 PM, Andre Schramm wrote:

> Hi,

Hi!

Sorry for kicking in so late, life's rather busy these days...

> we're having issues obtaining the correct system sample rate from PCI
> cards, while it works correctly for PCIe cards.



> hdspm.c:1988:   period = hdspm_read(hdspm, HDSPM_RD_PLL_FREQ);
>
>
> Output for PCIe card:
> hdspm_calc_dds_value: freq_const=110069313433624, period=2293110696,
> freq_const/period=48000
>
>
> Output for PCI card:
> hdspm_calc_dds_value: freq_const=110069313433624, period=41943044,
> freq_const/period=2624256

Weird. But if you say so, then yes, this would be the culprit.


> I tested with 3 different PCI cards (latest firmware) and the same
> card(s) works as expected on 32b-Kernel 2.6.24.7 with ALSA 1.0.16.

In 1.0.16, the driver simply returns hdspm->system_sample_rate instead
of calculating the rate via DDS.

What we can easily do is something (pseudo-code ahead) like:

    rate = calc_rate_via_dds;
    if (rate > 192k) {
       /* insane DDS value, use system_sample_rate instead */
       rate = hdspm->system_sample_rate;
    }
    return rate;

More like a workaround.

I'll send you a patch in a second.


> Within the driver, I don't see a different code path for PCI and
> PCIe, so this seems weird. I took a look at the Mac driver as well, it
> defines	RD_PLL_FREQ as 4*128, so this should be ok?

Yeah, the only explanation so far is that the PCI device is more different
than we tought.

> And the proc-output for the samplerate is wrong/misleading as it isn't
> read directly from the card as opposed to the RayDat-Code. Is there any
> reason for this?

Not that I'm aware of. Could probably use some refactoring. ;)



Cheers