lambda-audio

lambda-audio copied to clipboard

This library was working fine before, but just today I started getting this error without any changes in my function:

/tmp/soxi: error while loading shared libraries: libgomp.so.1: cannot open shared object file: No such file or directory

I wonder if libgomp was updated in the Amazon Linux AMI and the version of sox included in this lib is now outdated?

See commit in my fork with how I got around it. Not ideal... but it fixes it for the time being. https://github.com/jsonmaur/lambda-audio/commit/1117e428241579d343ce2f3cccf37d0e3e52ad86

I'm also having this issue. It would be awesome if we could get an updated package in npm (although maybe this isn't maintained any more?).

@jsonmaur - thanks for the workaround!

@jsonmaur & @TimothyJones I can't seem to get this working even when I set the environment variable... It's as if the lambda ignores the LD_LIBRARY_PATH value, or the sox lib is somehow compiled with a hard-coded path...?

You both were able to get this working? Could things have changed since June? Does it still work for you guys on a new Lambda function setup?

Thanks!

I’ll share my setup when I’m back at a computer, but I think the steps were:

1. Put the library in the deployment zip (I put it next to the binaries)
2. Figure out what path the library is at (it needs to be absolute), and set LD_LIBRARY_PATH to that.

It’s a bit of a hack, but it currently works in a lambda that runs daily.

I have the same problem. If you use NodeJS v8.10 it will work without any need for env vars or additional files to be added. If I switch NodeJS to > v8.10, it will not work regardless of env vars or adding the libgomp.so.1 .... Support for 8.10 will end soon. Do you have an updated version of lambda-audio for >8.10 ? Thanks! UPDATE: I created new binaries for sox and lame using Amazon Linux 2 AMI and then linked 'libgomp.so.1' in env vars and now it works on NodeJS 10+.

This is the env variable I used to get it working on node 10.x:

https://github.com/TimothyJones/WeatherReportAlarmClock/commit/e2b9386715cdaeae17ae0ad1cb02bc3be0dd64cb#diff-be18b73cd87a49e657b43a1d32a35e3c

(I put the library in the same place as the binaries in node modules, which you can't see in the repository)

Mine still seems to be running fine on Node 10.x. I have the libgomp.so.1 deployed under the lib64 folder, then set this environment variable:

LD_LIBRARY_PATH=node_modules/lambda-audio/lib64:$LD_LIBRARY_PATH

This is assuming I'm installing the package from my specific fork rather than NPM.

"dependencies": {
  "lambda-audio": "jsonmaur/lambda-audio#master"
}

Thanks everyone - I was using AWS environment variables to build the path ("$LAMBDA_TASK_ROOT/node_modules/lambda-audio/lib64") and apparently that didn't expand into a valid path... Substituting it for the full path, without variables, seems to do the trick:

LD_LIBRARY_PATH: /var/task/node_modules/lambda-audio/lib64:$LD_PRIMARY_PATH:$LD_LIBRARY_PATH

Now to figure out why sox can't see the downloaded file in /tmp...! (if you have any ideas, please let me know!)

Yeah, my sox/lame binaries were old so wouldn't work with Amazon Linux 2. @MacPrawn Not sure if this helps, but this is how I reference files for sox to work with: let temp_path = "/tmp/xxx.wav"; await FS.writeFileSync(temp_path,myaudiobuffer,{mode:0o777,encoding:null}); await LAMBDAAUDIO.sox(`${temp_path} -r ${newSampleRate} ${temp_path.replace('.wav','')}_resampled.wav`); full perms, but i then reload the audio to buffer and delete the file.

Thasnk @rayanarman ... Unfortunately didn't help. Funny thing is soxi has no problem opening the file and reporting stats on it... I'm guessing maybe the "No such file or directory" message from sox is a generic error that does not tell the whole story...

@MacPrawn Yep - I was seeing "No such file or directory", but when I ran it locally I found it was ENOENT - but then terminal showed the missing shared libraries message

@rayanarman Oh shoot - so you're saying the library will not work on Amazon Linux 2 at all anymore? I'll try to re-compile them, see if that helps...

Yeah, I re-compiled sox and lame but used the libgomp.so.1 from jsonmaur

I read and write to /tmp, feel free to have a look through the source linked above.

On 26 Nov 2019, at 12:27 am, Rayan Arman [email protected] wrote:

 Yeah, I re-compiled sox and lame but used the libgomp.so.1 from jsonmaur

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

@TimothyJones Thanks - interestingly, you use wait-on after the call to sox... Any particular reason?

I found sometimes the file didn’t exist immediately (not sure exactly why). It made the following call fail, so I worked around it with wait on. It’s... not the prettiest solution, but worked.

On 26 Nov 2019, at 1:28 am, Jean Le Clerc [email protected] wrote:

 @TimothyJones Thanks - interestingly, you use wait-on after the call to sox... Any particular reason?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

@rayanarman : I came across this issue again while doing some unrelated upgrades, but it seems that this repo is no longer maintained. Would you consider publishing your fork to npm?

@TimothyJones I am no longer using sox for my projects, but if you or @rayanarman send PR, I'll approve it. I can add you as contributors if you want to maintain this package.

You can also use Lambda containers now, and https://github.com/lambci/yumda can install sox and other libraries to AWS Lambda.