Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

optimization #1

Open
eiriklv opened this issue Jun 22, 2014 · 7 comments
Open

optimization #1

eiriklv opened this issue Jun 22, 2014 · 7 comments

Comments

@eiriklv
Copy link
Owner

eiriklv commented Jun 22, 2014

Some stuttering when adding to queue

Some operation is interfering with the playback. Experiment with it and try to mitigate it.

Might be oparations performed agains mongodb. Look into moving to a lighter database solution, and even memory.

The problem surfaces when alot of requests for the /api is done. Find a way to lighten the load when playing, and rather do updates between each song. Instead of fetching the complete queue each time, the updates should be pushed with socket.io.

Try to push the smallest amount of data to each user interface for every update.

Be sure to make everything non-blocking to the highest extent. Also try to limit cpu intensive operations that might interfere with the buffer stream.

@eiriklv eiriklv changed the title Stuttering when adding to queue optimization Jun 22, 2014
@IainCole
Copy link

Do you run the player in its own process?

@eiriklv
Copy link
Owner Author

eiriklv commented Jun 23, 2014

@IainCole No, currently it runs in the same process. But it should probably have its own. I haven't put much work into optimizing yet, as i just wanted it up and running before the weekend was over :) If you have any suggestions, just bring them on! :)

@eiriklv
Copy link
Owner Author

eiriklv commented Jun 23, 2014

@IainCole I thought about "oursourcing" the web interface to the cloud (heroku), but i really want to keep it as isolated as possible on the pi, so that i can create an SD-card image with everything you need to get started. Plug and play :)

@IainCole
Copy link

Yeah I found no matter how optimised the code, because the player is almost constantly piping data to the speaker, you have to run it in its own process in order to not interrupt the sound. It should be quite easy to just segment off the audio handling parts of the system to a separate process whilst keeping the rest of the logic for the web player in the other.

@eiriklv
Copy link
Owner Author

eiriklv commented Jun 23, 2014

@IainCole Sounds like a good idea! I actually did a similar approach for a version that used pifm for broadcasting Spotify over FM (would distort the sound if the process got "disturbed"), so it shouldn't take too long. Will make an implementation as soon as I have time this week :)

@eiriklv
Copy link
Owner Author

eiriklv commented Jun 24, 2014

@IainCole I have released a version with the player and web interface in separate processes now. You can find it under release v0.2-alpha or as the develop branch.

Haven't tested it on the pi yet (compiling takes a while..), but will do it soon :)

@eiriklv
Copy link
Owner Author

eiriklv commented Jun 26, 2014

Works great now! This way you can outsource the web interface, mongodb and redis to the cloud, to make it really fast, while still being able to bundle it all in on computer/raspberry pi if you want to

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants