Repository navigation
Implement callback API #2
Description
As noted in jacobcpeters@322a619 in @jacobcpeters fork the streaming callback API has proven a pain to implement. My results were similar and I was unable to come up with a solution the last time I worked on it.
I feel like there must be way to implement it, but the thread conflict seems to be prevented it in its current form. The last time I was looking at it I tried digging into node-lame a bit to see how it was being done, but I was unable to extract what we would need here to make it work.
Looking at some other libraries that may be helpful, another one of @TooTallNate's libraries node-speaker may be more insightful. As there is much less to dig through ;).
Given my lack of experience with native bindings (C++ for that matter), I've still not nailed down what will need to be done. I'm going to dig into it a bit more in hope that we can implement PortAudio's callback API along with the blocking API.
Activity
jacobcpeters commentedon May 7, 2016
The inherent problem is that getting the pcm data from javascript to PortAudio requires an asyncronous call. I don't think this is a insurmountable hurdle. We can either block the callback until we get the data require, or implement a double queue for the data.
The blocking method doesn't seem desirable. We have zero control over when libuv will allow the call. Also, at that point, it seems more prudent to just implement the callback in javascript utilizing the blocking API function that I am close to having implemented in my fork.
The double queue means that the javascript callback will always be at least a step behind on the output. This means that there will always be added latency to the output. However, I still think this is the better option.
doesdev commentedon Jun 1, 2016
Okay, it took me quite some time to wrap my head around the problem and realize exactly what you had already laid out very clearly here ;)
So to make sure I'm understanding right, the only real option would be to run the js callback in the uv thread, block the js callback until we get a result from uv's after_work_cb, and then complete the js callback and return it to PA. I'll try and work on that a bit to see if I can make any progress with it.
jacobcpeters commentedon Jun 1, 2016
That is exactly how I was planning to tackle the problem. I've been a little busy lately. Sorry for the lack of new commits.
The last time I looked, I was thinking of subclassing the Nan::AsyncWorker class. Look at that class if you want to see how the libuv functions should work.
Merge pull request #2 from jacobcpeters/input-functions
jacobcpeters commentedon Jun 22, 2016
I had a major breakthrough! In the callback branch of my fork, I currently have a javascript callback being requested from the PortAudio thread. So far, it's just triggering a callback that prints "Callback" to the command line, but it shouldn't be too difficult to iterate on that until there is full support for callbacks written in javascript.
At this point, I think every PortAudio function can be implemented in some fashion.
jacobcpeters commentedon Jun 23, 2016
The test script in my callback branch is now outputting a sine wave. Everything needs some slight refinement/refactoring, but it should be pull request ready soon.
doesdev commentedon Jun 23, 2016
That is awesome. Thanks for all your great work on this.
tonetechnician commentedon Apr 22, 2019
Hey there, just wanted to know if this problem ever got solved?
Thanks!
doesdev commentedon Apr 23, 2019
Yes, it should be fixed in Jacob's PR. That was a failure on my part, it should have been merged when it is added. I'm going to close this in favor of that PR.