The "Songcast OHM/OHU Protocol Specification (Version 1.0)" specifies the transport of decoded PCM samples. The field "CodecName" just describes of the codec which was used to decode the audio stream to PCM.
The drawback of using PCM for casting the audio stream is that it limits the bandwidth of the Songcast Sender or the Primary Slave. This does matter for small embedded wireless systems where wifi bandwith is limited to 10-30Mbps.
A single unicast PCM stream (44.1kHz,16-bit,2ch) has a bandwidth of 1.4112Mbps. So this limits the number of receivers to something between 4 and 6 and the lower limit.
I've been playing with encoding the PCM stream on the Sender side to FLAC and decoding the stream on the Receiver side likewise. The encoded FLAC stream only has a bandwidth of 0.5-0.8Mbps allowing to increase the maximum number of Receivers the Sender can cast up to 12.
The drawback of casting an encoded audio stream is the incompatibility with the Songcast protocol.
So I'm asking about your opinion about the issue and if you are willing to merge the functionality of encoding the stream with FLAC (and Opus) if I'm making a request. The codec could be defined on the command line or the user command handler and defaults to PCM.
Discussion
-
medoc
2018-06-01It makes a lot of sense to do this. Roon and LMS do it. As long as it's optional, I dont' see an issue with breaking compatibility with Linn receivers. We can define the codec in the configuration.
There are probably other issues though. For example how do you handle a receiver connecting while the stream is playing ? You can't just start a FLAC stream at any packet ?
-
jk
2018-06-06I've prepared a merge request https://opensourceprojects.eu/p/sc2mpd/code/merge-requests/13/.
The receiver can indeed connect while the FLAC stream is already streaming. Furthermore, does not need to be restarted if the sender is restarted using another codec.
-
medoc
2018-06-06I'll be away for one week, with not a lot of time, but I'll look at it as soon as I can.