Ending

[jamen]

to destroy read/write streams:

player.end(err)

I was having trouble getting this to work on browser though. It either says I can't call node.start more than once, or it keeps playing forerver if I pass the newly created node.

[dy]

Not sure I get the thing. audio-play was not designed to be a stream, it is not actually. It was created to prelisten audio buffers. Why should we provide end method? Is there a use-case for that? If we want to have a through-stream that outputs data to speaker, we should think about modifying audio-speaker.

[jamen]

I wasn't thinking of the end as a stream in this case. In my code I have this:

let player = play(track, opts, done)
// ...

Then for e.g. an error happens somewhere, or the user wants to stop playing the track with no intent to resume, I would use player.end(err) which would stop playing and do the callback. Also prevents subsequent play/pause calls, and closes the streams properly when they are no longer needed.

Edit: Maybe player.stop(err?) would make more sense in context of a player.

[jamen]

Maybe what I'm looking for is more higher-level than the purpose of this module.

Because, I need functions to stop, go forward/backwards, maybe swap out the buffer being played, etc. for more fine control over writing to audio-speaker. But the name of this seems to fit. :stuck_out_tongue:

[jamen]

For context: I started developing audio-player-cli today which will be an app more than a command.

The user sends input codes which control the player (pause/play, move, stop, etc.), and also visualizers.

[dy]

Oh, now I get it. Yes, stop is more of the player context (also web-audio-api uses that name), I also was thinking about that, but did not find a case where it seriously differs from pause. You mean it is like destroy, or dispose, where we get rid of references to objects?

Then yes, makes sense - disconnects nodes etc.

I would stick to camelCase than lo_dash conventions in code (it is PHPy style). Also let's rename it to stop.

[jamen]

@dfcreative I've updated the branch. The tests seem to be failing for me, but master is also failing.

[dy]

@jamen does it? For me master worked fine yesterday. Ok I will try to look at it this evening.

[jamen]

@dfcreative

audio-play (master) $ npm test

> audio-play@2.2.0 test /home/jamen/audiojs/audio-play
> node test.js

/home/jamen/audiojs/audio-play/test.js:11
buf.getChannelData(0).set(samples)
                      ^

RangeError: Source is too large
    at Float32Array.set (native)
    at Object.<anonymous> (/home/jamen/audiojs/audio-play/test.js:11:23)
    at Module._compile (module.js:569:30)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:503:32)
    at tryModuleLoad (module.js:466:12)
    at Function.Module._load (module.js:458:3)
    at Function.Module.runMain (module.js:605:10)
    at startup (bootstrap_node.js:158:16)
    at bootstrap_node.js:575:3

[jamen]

Also, whoops, I forgot to update browser.js

[dy]

@jamen yeah, I see, strange - yesterday it worked, now updated node to 8.1.2 - same version as in travis, but it works locally, although speaker package stopped working. So seems that we have to focus efforts on audio-speaker, that is an old problem, and there is still no alternatives to node-speaker. Ideally API should be just let write = Speaker(options); write(audioBuffer|data, callback);

[jamen]

@dfcreative For sure. I see unresolved issues pop up there every now and then as I watch it, it would be great to have audio-mpg123 as a more maintained alternative.

I have been working on many things this week, but I'll defs continue on https://github.com/audiojs/audio-mpg123/pull/10. I actually haven't used much C++ to this prior, though. So if you or you know anyone with more experience, that would speed things up for me (either some explanations or resources, or just taking over the branch). Currently trying to understand N-API's Asynchronous Operations, which I drafted something in the branch for, although it is broken.