Gregory's Server@hailey this looks interesting.
How do you deal with long-term clock drift between your receivers? Is there some logic to resample the audio to match the clocks or do you wait until the buffer over/underflows and then jump?
|
8 comments
 @hailey nice! do you have plans on integrating it somehow with mpd? I'd be especially interested in a way to use mpd to select on which devices I want to output audio. mpd has the concept of "audio_output" and most mpd clients allow you to control them.  @electronic_eel no special integration needed! You can create a virtual duplex device in both Pipewire and Pulse, configure mpd to play to that device, and bark to capture from that device - see the readme for more info @electronic_eel I see! You could achieve this by creating separate virtual devices and running multiple bark stream processes using separate multicast groups for each speaker. You'd lose the benefit of multicast, since you'd essentially be unicasting to each speaker (but in a roundabout way via multicast), but the actual synchronisation runs according to CLOCK_BOOTTIME on the source host, so provided all stream sources are running on the same machine the sync would work. @hailey ah, cool! I don't care about network bandwidth as all sinks have direct ethernet cables to one switch. So unicast or multicast doesn't matter for my application. I think I will give bark a try soon.  @hailey @electronic_eel speex-dsp for resampling is an interesting choice. Why use a C library over Rubato? |
@electronic_eel yes it uses the speex-dsp resampler and it will slew to resync for small offsets, and jump for large discontinuous offsets!