Indeed. Your biggest problem is that the sound cards in each machine will have very slightly different clock frequencies, so will naturally drift apart from each other. The job of the server software is essentially time base generation; the job of the client software is queue management such that the audio that is being played is not too far away from the time base (essentially clock regeneration, except through resampling rather than generating a real clock).
The fact that your time base is being broadcast over a network means that there will be some problems: the further away in network terms the client is, the more jitter it will perceive. With any luck, though, the long term average will be useful for tuning audio clocks.
Clients could also ignore the time base and just look at the received audio packets: how full is the queue? If it's above a threshold, increase the audio clock (or start dropping samples); if it's below, decrease the clock or start duplicating samples.
Broadcast digital audio (digital radio / tv) has the nice property that the audio clock can be recovered from the broadcast signal using a simple PLL. Assuming your network packet frequency isn't too low (consider the number of samples encoded in a packet; and are you sending VBR compressed audio?) you may be able to do a similar trick.
no subject
Indeed. Your biggest problem is that the sound cards in each machine will have very slightly different clock frequencies, so will naturally drift apart from each other. The job of the server software is essentially time base generation; the job of the client software is queue management such that the audio that is being played is not too far away from the time base (essentially clock regeneration, except through resampling rather than generating a real clock).
The fact that your time base is being broadcast over a network means that there will be some problems: the further away in network terms the client is, the more jitter it will perceive. With any luck, though, the long term average will be useful for tuning audio clocks.
Clients could also ignore the time base and just look at the received audio packets: how full is the queue? If it's above a threshold, increase the audio clock (or start dropping samples); if it's below, decrease the clock or start duplicating samples.
Broadcast digital audio (digital radio / tv) has the nice property that the audio clock can be recovered from the broadcast signal using a simple PLL. Assuming your network packet frequency isn't too low (consider the number of samples encoded in a packet; and are you sending VBR compressed audio?) you may be able to do a similar trick.