Feature request: set input channel # to reduce CPU and upload bandwidth (and have Orcasite make stereo from mono)

scottveirs commented 5 years ago

Streaming/archiving only a single channel could be a good idea, e.g.

for nodes at which stereo signals aren't a priority (single hydrophone; or no localization, only redundancy from dual hydrophones)
for nodes at which one of the two signals fails (e.g. due to Neptune/gremlins)
for nodes that are limited by upload bandwidth
to halve storage costs and space requirements

If the Orcasite player could generate a stereo stream from a mono stream, then it could do so if it

detects a mono stream, or
learns that a stream is mono (e.g via an API call to Resin about the node?).

mcshicks commented 3 years ago

Should this be on orcasite instead of orcanode?

scottveirs commented 1 year ago

Thinking about this again after using CHANNELS=1 vs CHANNELS=2 to troubleshoot the high-frequency noise on the Orcasound Lab feed...

I just checked in S3 to compare files sizes betwee the successive restarts of the streaming container. All other .env file variables remained the same.

When CHANNELS=2 the file size is ~195 kB for a 10-second HLS .ts segment.

When Channels=1 we are saving bandwidth. I think ffmpeg is successfully taking a single input channel and mixing it to generate a smaller file size 107 kB (again, for a 10-second HLS .ts segment). So, I conclude the streamed file is single channel (mono), but the Orcasound player (on OSX/Mac/Chrome) presents it in stereo, i.e. the same mono input channel in both left and right ears.

I haven't checked CPU usage on the Raspberry Pi in each mode, but will close this issue for now.

orcasound / orcanode

Feature request: set input channel # to reduce CPU and upload bandwidth (and have Orcasite make stereo from mono) #11