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