Thanks a lot! :) The prefix is related to the way STEEM blockchain internally works and the available queries that are available. To enable browsing for tags, which I think is crucial for DSound I had to have a way to isolate only DSound posts, so that's why the prefix. But you're right, maybe there are some improvements to be made... ;) DSound is not opensource for now... It probably will in the future, but after it get's enough maturity to have a live of it's own...
You are viewing a single comment's thread from:
Fair enough. I was just offering to help.
Are you aware of RAM usage issues when processing audio? The browser process (I've tried both FF-Beta and Chromium) requires multiple gigs to process file that's <512MB. Doesn't seem to make a difference whether its flac, wav, or mp3.
Also, it would be nice if a remote IPFS node can be specified - it would be a lot more convenient to have my node running in a jail on my fileserver than locally.
Yes, RAM is like that because DSound has to be decentralised... So all the processing has to be done in the browser, meaning the decoding of the entire file and processing to extract the audio peaks required to generate the waveform... The longer the sound, the higher the RAM needed. :)
That makes perfect sense. I forgot about waveform generation when wondering what was so inefficient when it comes to RAM usage. Could this possibly be remedied with a browser extension (or CLI uploader or something)? With a user defined IPFS node, I could just use a VM with enough RAM defined for the upload to an IPFS node on my local network without having to jump through extra hoops to keep the data online after uploading.
Thanks for the ideas, noted down! :) This will have to be improved, so will put some thoughts on that soon...