wrong sample rate with elder release?

[DrCWO]

Hello,
I use your package since quite a long time now.

Recently I discovered that using a sample Rate of 176400 my RME ADI-2/4 audio interface jumps to 192000. This happen sometimes, not always. Is this a known issue fixed with the latest release?

My current release says:

{
    "name": "alsa-capture",
    "version": "0.2.2",
    "description": "capture alsa pcm packages",
    "main": "index.js",
    "scripts": {
        "test": "echo \"Error: no test specified\" && exit 1",
        "install": "node-gyp rebuild"
    },
    "dependencies": {
        "eventemitter3": "^4.0.7",
        "nan": "^2.15.0",
        "node-gyp": "^8.4.0"
    },
    "devDependencies": {},
    "repository": {
        "type": "git",
        "url": "git+https://github.com/meldron/node-alsa-capture.git"
    },
    "keywords": [
        "alsa",
        "capture",
        "microphone",
        "pcm"
    ],
    "author": "Bernd Kaiser",
    "license": "MIT",
    "gypfile": true,
    "bugs": {
        "url": "https://github.com/meldron/node-alsa-capture/issues"
    },
    "homepage": "https://github.com/meldron/node-alsa-capture#readme"
}

[DrCWO]

Just downloaded the latest release 0.3.0 but the issue remains with 176400. The RME ADI-2/4 always sets the rate to 192000 and I get a "rateDeviating" event.

This here looks like my issue...
https://stackoverflow.com/questions/35480928/alsa-unexpected-results-when-called-from-shared-library

[DrCWO]

I guess the reason lies in the dir parameter:

I learned:
snd_pcm_hw_params_set_rate_near uses a direction (dir) parameter.
When the exact rate isn't available:
If dir = -1: ALSA looks for the nearest rate lower or equal to your request.
If dir = 0: ALSA looks for the exact rate.
If dir = 1: ALSA looks for the nearest rate higher or equal to your request.
If dir is uninitialized or evaluated at 1, ALSA will force the switch up to 192 kHz.

In capture.cc the dir parameter is defined as int dir; but never set to zero!

[DrCWO]

I finally managed to add dir=0; in capture.cc after its definition and rebuild capture.node.

Believe it or not this fixed the issue :-)

Would be great to see a release 0.3.1 with this fix.