Open kgoderis opened 7 years ago
maggu2810
commented
7 years ago How do you plan to sync different sinks without knowing how the sinks handle the stream itself? Isn't there a requirement that you need to know a lot of details of the sinks itself (different cache strategies, delay caused by internal stream processing etc.)?
kgoderis
commented
7 years ago @maggu2810 In fact, as you point out, you can't. The only thing you can do is make sure you "stream" to them at the same time. How they finally handle it is up to the implementation. In this respect, perfect audio syncing might not be achieved. But, as it stands right now, even within a single binding like Sonos stuff is not played very well in sync (it kinda works with a low number of players, but I have 20 something of them, and it gets jerky). I think that internal delays and so forth are hard to solve. The only thing you could do is to push the functionality as close as possible to the execution in the Handlers. When I try to do things "in sync" within the DSL Rules (using Timers,...) , it simply does not work very well.
My idea would be to make use of SafeCall when handing over the AudioStream to the Sink, instead of processing this sequentially.
The Sonos system has a mechanism to group and ungroup players, and act upon them simultaneously. Grouping and ungrouping players can be done from the DSL using Items that are linked to specific channels for this purpose (e.g. "add" and "remove"). However, the time for players to process the commands to group/ungroup is widely variable and not consistent. The alternative approach, which consist in grouping Items that are bound to the same Channel (e.g. "playuri") of various players, and issuing a Command to that Group, results in audio that is played out of sync or that is flaky altogether, and it not suitable for mp3 or other files that need to be served from the AudioHTTPServer.
The proposal/idea would be to extend the Audio action with a series of DSL-usable commands to (1) group and ungroup Sinks and (2) play Audiostreams to these groups, including setting the volume, and (3) play AudioStreams to more than one Sink at the time using a regular expression to select the Sinks to play to. Moreover, the Audio action should be altered to make SafeCalls so that concurrency is introduced, and audio is produced in sync over all sinks.
In other words, reproduce the Sonos concept of grouped players at the level of the AudioSinks, so that this can be applied to other types of AudioSinks that do not natively have a similar grouping feature