Buffers are part of what introduces the problem in the first place .. please read my other thread on this subject. You would have to introduce some kind of distributed millisecond level sync system... simply not practical. The only way syncd play is ever going to work is by using a genuine realtime stream (ie analoguous to fixed wires/single source) to all locations simultaneously, preferably using multicase, but broadcast would work just as well. And no buffers at all. Even then, the variable bit rate nature of most compressed audio streams is likely to cause problems. After reviewing the "broadcast" option of Xine, it seems that it isn't a genuine broadcast at all, it is just multiple unicasts which won't work.

No, buffers fix the original problem. You don't have constant latencies/bandwidth on a packet based network. IP/Ethernet is not ATM/. I don't see how this should ever work without using buffers. So you have to sync them with timecodes. And thats exactly what the slimdevices guys are doing.

The original problem? If you mean break up in playback because of variable latency/bandwidth then I would agree with you. But I believe we are talking about the sync issue... if so, then no, buffers are the main cause of this issue on a local segment! The fact that you are using a buffer, that fills and empties on demand as bandwidth/latency varies means that you can never get an exact sync because there is no correlation between when the packet data arrives and when it actually gets played - it depends as much on the size of the buffer, how long the playback mechanism waits before playing back, etc. That can easily all vary between playback devices causing a loss of sync....

I agree that IP is not ideal nor guaranteed over routed subnets (particularly the Internet), but on a local switched segment, a buffer is not needed to deal with variable latency (by which I mean a large buffer, the playback device will always have like a tx-ring type, tiny fifo to queue) as the latency on a local switched segment is tiny and hardly varies at all until the interface is already congested - at which point playback would fail for any technology.

What I'm trying to say is, I agree a buffer is absolutely required on routed streams over distance, without which the stream will stutter, fart, crap out, etc. But on a local segment, the steam can be made to work reliably without a buffer, and the buffer is the main thing that will screw up sync.....

That being said, even with a buffer (assuming all the MDs use the same size buffer!) as long as LMCE used a UDP broadcast or multicast stream, this would significantly reduce the sync issue, as it is perfectly clear that in LMCE's case, the most significant issue for sync is the xine devices starting playback based on the last timestamp that media plugin received, which even if xine started playing back the stream instantly, could still be out by as much as 1 second!!!

The original problem? If you mean break up in playback because of variable latency/bandwidth then I would agree with you. But I believe we are talking about the sync issue... if so, then no, buffers are the main cause of this issue on a local segment! The fact that you are using a buffer, that fills and empties on demand as bandwidth/latency varies means that you can never get an exact sync because there is no correlation between when the packet data arrives and when it actually gets played - it depends as much on the size of the buffer, how long the playback mechanism waits before playing back, etc. That can easily all vary between playback devices causing a loss of sync....

I agree that IP is not ideal nor guaranteed over routed subnets (particularly the Internet), but on a local switched segment, a buffer is not needed to deal with variable latency (by which I mean a large buffer, the playback device will always have like a tx-ring type, tiny fifo to queue) as the latency on a local switched segment is tiny and hardly varies at all until the interface is already congested - at which point playback would fail for any technology.

What I'm trying to say is, I agree a buffer is absolutely required on routed streams over distance, without which the stream will stutter, fart, crap out, etc. But on a local segment, the steam can be made to work reliably without a buffer, and the buffer is the main thing that will screw up sync.....

That being said, even with a buffer (assuming all the MDs use the same size buffer!) as long as LinuxMCE used a UDP broadcast or multicast stream, this would significantly reduce the sync issue, as it is perfectly clear that in LinuxMCE's case, the most significant issue for sync is the xine devices starting playback based on the last timestamp that media plugin received, which even if xine started playing back the stream instantly, could still be out by as much as 1 second!!!

Look at the Logitech and the Squeezebox... the devs there have been trying to get sync'd audio working since before the first Squeezebox's his the market. Now to all intents and purposes they have exactly the same hardware playing their stream in each zone... and they are now using a 'heart beat' and they still cannot get sync'd playback to work at a level that compares with a source routed through a multi-zone amplifier - that is the benchmark pure and simple i'm afraid.

Its very frustrating as we'd all like a pure digital solution to this - I certainly would as it would make my life so much easier!

This might sound totally off the wall, but I have used the technology before (obviously a different application) and it worked well.

What about using a FM modulator on the core (or whichever pc you use for playing home audio) and broadcasting your audio to the rest of the tuners in your house over FM waves. You could easily set up a scenario that would flip your AV reciever into tuner mode and have the station preset to whatever your modulator is on. This of course would require each audio station to have a FM reciever, but I know in my situation that is the case.

I have used these devices before with success, although both times my reciever was only about 10ft from the transmitter so I am not sure what kind of range they have. But both times the audio was crystal clear and if you use this method I would bet you there would be no detectable sync issues.-Krys

I have not yet had time to investigate this further, for synchronization accuracy, but the claim is that it is perfect. I really think PulseAudio (http://pulseaudio.org/) is a viable option for multi-room audio playback. There are many features which could be desirable to LinuxMCE users:

- It will output synchronous audio to multiple networked computers- It will output synchronous audio to multiple sound card outputs in a single computer- It will output individual sound sources to different sound card outputs in a single or multiple computers (this allows it to operate like a matrix switch without latency issues with multiple sound card outputs from a single pc)- It allows you to use remote inputs (microphones) as local devices (baby monitor?)- It uses a timer based method of synchronizing audio across networked pcs- It is already incorporated as the default sound system in (k)Ubuntu 8.04 and up- It uses zeroconf (avahi) for auto-discovery of networked pulseaudio systems (easily discoverable like remote shares...)- It has a command line interface for all functionality (looks fairly easy to interface with...)

Why re-invent the wheel? It is already the default sound system in Ubuntu...

Is PulseAudio capable of providing synchronized audio playback over the network for movie players like MPlayer?

Yes! Unless your network is congested in some way (i.e. transfer latencies vary strongly ('jitter')) it works perfectly. ...

I'm still working my way through understanding the entire system but my understanding is that a device template could be written to use PulseAudio sinks (outputs) similar to how squeezeboxes are implemented. I don't know how this would be done.

Many linux distros use PulseAudio (windows support as well) XBMC also uses PulseAudio now. Many options for network capable audio players open up by incorporating PulseAudio support.

Link for what I am talking about... obviously this is made for a car so range could be an issue. I will try to find some specs.

These are great devices, I have one of these in my car. I does not broadcast an FM signal though, it is simply a modulator, not a transmitter. It would allow you to modulate an audio signal onto an FM carrier frequency which you could then connect to the FM Antenna input on a receiver, this could probably be distributed through coax cable and a couple of splitters. As a minimum it would allow a single FM radio device with an external antenna input to receive an audio signal from a single device with RCA style outputs. These devices are not regulated because they do not 'broadcast' their signal through the air, only within a wire.

FM transmitters are limited in power (and therefor range) by broadcast regulators (CRTC here, FCC in the US, etc..). Without a licence from a regulatory body FM transmitters are limited to the approx. 10' you've mentioned. I've used some that will do 20' on fresh batteries. These devices can sometimes be modified for higher broadcast power but you are then in violation of FCC/CRTC regulations. I've not seen an FM transmitter that does not run on batteries (I assume for transmit power purposes) because they are usually intended to be portable, like for your car.

Link for what I am talking about... obviously this is made for a car so range could be an issue. I will try to find some specs.

These are great devices, I have one of these in my car. I does not broadcast an FM signal though, it is simply a modulator, not a transmitter. It would allow you to modulate an audio signal onto an FM carrier frequency which you could then connect to the FM Antenna input on a receiver, this could probably be distributed through coax cable and a couple of splitters. As a minimum it would allow a single FM radio device with an external antenna input to receive an audio signal from a single device with RCA style outputs. These devices are not regulated because they do not 'broadcast' their signal through the air, only within a wire.

FM transmitters are limited in power (and therefor range) by broadcast regulators (CRTC here, FCC in the US, etc..). Without a licence from a regulatory body FM transmitters are limited to the approx. 10' you've mentioned. I've used some that will do 20' on fresh batteries. These devices can sometimes be modified for higher broadcast power but you are then in violation of FCC/CRTC regulations. I've not seen an FM transmitter that does not run on batteries (I assume for transmit power purposes) because they are usually intended to be portable, like for your car.

J

Something within my expertise

Is it possible to do this within a core or a media director?

The way it works on a hotel system is thus:

You take any channel from a satellite/Cable receiver and you input it into a modulator(composite) and assign that modulator a channel number. You can do this with multiple Modulators and combiners (looks like a backwards splitter) in order to assign many receivers to create a full out channel lineup. The modulators transmit an RF signal through coax to your TV. You would now tune into that particular channel to receive what ever channel the receiver is set on. This type of system is very commonly found when modulating cameras into the cable signal that the cable TV companies provide.

BECAUSE it is a Closed caption signal, the strength of the signal running through coax doesn't need to be that strong so there wouldn't have to be that much worry about range. If there were a low quality signal the signal could be amplified at source to produce a better quality signal. Optimal signal to any device is 0db/mv (decibels/ milivolt). This signal strength can be measured using a RF signal strength meter.

Receiving channels on a TV tuner card would ensure a synced analog signal provided by the core.

Now forgive me I am so used to winblows I do not know this answer at all.

If a core computer had multiple Audio cards within it... could it do audio switching. Does Linux allow for multiple audio cards at once to within one computer? Would they be at almost perfect sync?

If this is possible I could assign an audio card to a particular room and viola I could have a multi-room controller built within the Core.I wouldn't need to have a bunch of cheap media directors to play audio only within them.

These devices are intended to be plugged directly into a car stereo and would require modification to use otherwise. It's not meant meant for home system use, there are devices for that purpose, such as amplified matrix distribution systems.

If a core computer had multiple Audio cards within it... could it do audio switching. Does Linux allow for multiple audio cards at once to within one computer? Would they be at almost perfect sync?

If this is possible I could assign an audio card to a particular room and viola I could have a multi-room controller built within the Core.I wouldn't need to have a bunch of cheap media directors to play audio only within them.