Hello,
Regarding the various music server implementations, I worry about the popular server-to-client streaming model.
Can anyone comment about this concept from a hi-fi point of view, please?
Even if we assume that the server-client connection is by ethernet, not wifi (thus no data loss) I still wonder whether the audio data sent via network protocols is conducive to good quality DA conversion once it reaches the client.
Do media player applications adequately buffer this audio data?
Do good quality computer DAC's, such as asynchronous USB DAC's, adequately buffer or reclock the data?
Regarding the various music server implementations, I worry about the popular server-to-client streaming model.
Can anyone comment about this concept from a hi-fi point of view, please?
Even if we assume that the server-client connection is by ethernet, not wifi (thus no data loss) I still wonder whether the audio data sent via network protocols is conducive to good quality DA conversion once it reaches the client.
Do media player applications adequately buffer this audio data?
Do good quality computer DAC's, such as asynchronous USB DAC's, adequately buffer or reclock the data?
As I understand it a digital stream either gets to the receiver in an OK state or it doesn't. If it doesn't then you hear obvious clicks and pops. So there is no gradual degradation in sound like you would get with analogue.
Cable based protocols are going to deliver bit perfect data streams unless there is a serious mechanical problem with the cable. That's been my experience with digital transmission via TOSLINK (8 simultaneous channels, 24 bits each, 48k sample rate, 10m cable) and with WiFi. With WiFi if the signal strength falls below some specific level then the pops start, otherwise the quality is bit perfect. With my Squeezebox receivers they buffer the data in case the signal drops out but obviously once the buffer is empty the signal is muted because there is insufficient data.
On that basis it doesn't matter whether you're using cable or wireless, the data quality will be the same, if the data stream arrives intact. Therefore the resultant sound quality will depend on the DAC, and these days they are all good enough to produce superlative audio.
OK, thanks.
Hearing your positive experience with such systems prompts me to proceed to experiment with various server applications (under Linux) ...
such as SqueezeCenter, Firefly, Tangerine etc.
But I should have been more clear with my questions. My queries can be condensed into 2 parts:
i) potential irregularity of the audio stream, and if so, its effects.
You seem to indicate that there are no obvious problems in this regard.
ii) data integrity. In this regard, I remain unconvinced about wifi.
My understanding of "streaming" is that, by definition, there is no "handshake" between server and client, and thus the integrity of the data cannot be assured. I'm referring to the streaming protocols I'm aware of, such as UDP and RTP -
User Datagram Protocol - Wikipedia, the free encyclopedia
Real-time Transport Protocol - Wikipedia, the free encyclopedia
As we have discussed, the absence of any handshake or error-checking is not an issue when the delivery mechanism is reliable, such as via ethernet.
But if/when a wifi signal drops out, the client misses the audio data for this period. The server has no way of knowing about the missing data, and the stream continues regardless.
No amount of buffering can change this. What's missed is missed.
The missing data may not necessarily result in a click, pop, or silence. The playback application at the client may "predict" or "average" the missing data, resulting (probably) in a dull patch of audio.
And this is my point: with wifi the data stream has the potential to be sometimes intact, sometimes not.
Hearing your positive experience with such systems prompts me to proceed to experiment with various server applications (under Linux) ...
such as SqueezeCenter, Firefly, Tangerine etc.
But I should have been more clear with my questions. My queries can be condensed into 2 parts:
i) potential irregularity of the audio stream, and if so, its effects.
You seem to indicate that there are no obvious problems in this regard.
ii) data integrity. In this regard, I remain unconvinced about wifi.
My understanding of "streaming" is that, by definition, there is no "handshake" between server and client, and thus the integrity of the data cannot be assured. I'm referring to the streaming protocols I'm aware of, such as UDP and RTP -
User Datagram Protocol - Wikipedia, the free encyclopedia
Real-time Transport Protocol - Wikipedia, the free encyclopedia
As we have discussed, the absence of any handshake or error-checking is not an issue when the delivery mechanism is reliable, such as via ethernet.
But if/when a wifi signal drops out, the client misses the audio data for this period. The server has no way of knowing about the missing data, and the stream continues regardless.
No amount of buffering can change this. What's missed is missed.
The missing data may not necessarily result in a click, pop, or silence. The playback application at the client may "predict" or "average" the missing data, resulting (probably) in a dull patch of audio.
Yes, "if".
And this is my point: with wifi the data stream has the potential to be sometimes intact, sometimes not.
I did follow some of the Wikipedia links. I must admit it quickly got way beyond my expertise or knowledge in this area (such are the joys of embedded links😉.)
I did notice that the 802.11 protocol (which the WiFi stuff uses) has a checksum field in the data frame, to see if the packet has arrived intact. Also there appears to be a 'retry' field, but I don't know if this is used in the Squeezebox implementation - that is, ask for a resend of a corrupted packet. Interestingly when I've had signal dropouts the track playing doesn't seem to skip ahead, just a pause then it sounded as if the data had been received again from the transmitter - this of course wasn't a rigorous test, just my perceptions.
As I said, the details of the protocols used are really outside my zone of knowledge so if any of the experts who might be out there could enlighten me (us?) it would be appreciated.
OK, I did some digging.
The SqueezeBox server application uses its own proprietary protocol: "SlimProto".
SlimProtoTCPProtocol - SqueezeboxWiki
This is a TCP protocol, and therefore has full data integrity.
A quote from here explains it in detail
Transmission Control Protocol - Wikipedia, the free encyclopedia
But all is good with Slimserver. I'm happy.
I will need to do some more digging to discover if the other options (UPnP, DNLA, OpenDAAP) have full data integrity.
The SqueezeBox server application uses its own proprietary protocol: "SlimProto".
SlimProtoTCPProtocol - SqueezeboxWiki
This is a TCP protocol, and therefore has full data integrity.
A quote from here explains it in detail
Transmission Control Protocol - Wikipedia, the free encyclopedia
You can see why I was concerned. Streaming implementations with which I'm normally familiar are optimised for timely delivery ... at the expense of accurate delivery.
But all is good with Slimserver. I'm happy.
I will need to do some more digging to discover if the other options (UPnP, DNLA, OpenDAAP) have full data integrity.
Oh, and now we know that SqueezeCenter uses TCP, or more accurately; SlimProto-over-TCP,
you can see why I was concerned about irregularity of the data stream.
To requote the wikipedia explanation of TCP:
you can see why I was concerned about irregularity of the data stream.
To requote the wikipedia explanation of TCP:
I wonder how this affects jitter?
It depends on whether slimProto is more for time delivery or data integrity.
If data integrity, then the receiver just needs a decent size buffer to handle errors(resends) and/or delays.
It really depends on the actual streaming protocol. The underlying factor is presence of the DAC clock on the receiving side. If the streaming protocol involves feedback controlling the pace of data flow, no asynchronous sample rate conversion is required on the receiving side and bit-perfect transmission is possible. That is e.g. the case of SB, inferring from the protocol documentation. A regular streaming without any feedback from the client (which is the case of most internet streaming scenarios) requires modifications to the incoming stream to fit the receiving side clock. There are numerous strategies varying in complexity and calculational demand (from simple dropping/adding samples to quality resampling). In my view none of them fullfill audiophiles requirements since they always involve modyfing the stream.
My opinion is purely based on listening - not understanding the data (or even half of your previous conversation) but I have just installed Squeezebox to go with my iMac, streaming uncompressed WAVs and there is absoloutely no question as to whether it has the capability to satisfy hi-end credentials. The jump up from a regular £1000 CD player is phenomenal and I am astounded by the results. Even internet radio has more depth than CDs!
This might be hard for you to "get" (for OP)
To OP: The squeezebox just plays the music. Mine is implemented via wireless. Playing Flac @ 24/48. From an information perspective, no different than listening to a CD or LP.
You can always go cabled Ethernet. You're letting the theoretical problems get in the way of hearing the music.
To OP: The squeezebox just plays the music. Mine is implemented via wireless. Playing Flac @ 24/48. From an information perspective, no different than listening to a CD or LP.
You can always go cabled Ethernet. You're letting the theoretical problems get in the way of hearing the music.
No I'm not. Re-read post 5.
I'm happy to learn that Squeezebox sounds good to audiophiles, and based on the positive reports I will probably use streaming audio in the near future, though not necessarily via Squeezebox.
It's sensible practice to check and challenge the theory.
Dont forget the comments regarding TCP are for high usage wide area networks with multiple users. If you are on a home system with a couple of users or so you wont have the same latency problems. Any NAK packages will be re-sent fast enough that you probably wont notice.
linuxfan said:
Always! And I like how you've gone about it - you've answered a question that I hadn't thought to ask.
In summation, it seems:
- Avoid UDP (and any other unreliable schemes).
- Wi-fi is fine (probably by design, but doubly-so if TCP is used over it).
I've been rather impressed with the VLC and VideoLAN group's recent advancements:
Their free and open source cross-platform VLC Player and Streaming Manager is all I'd use.
Not to drag 'video' into this but their X264 group has recently announced the first free software encoder to be able to generate Blu-ray compliant video and on a std. DL DVD disk....I seriously doubted that until I burned a 'trial' they have available.....best tech comes from the free and open source rebels. They started as French students wanting to broadcast campus wide but were denied a 'broadcast permit'.
Prue 'free-will' brings us all:
VideoLAN - VLC: Free streaming and multimedia solutions for all OS!
Combine the increasing acceptance of the Matroska 'container' with it's abilities and disregard of 'file type/format/proxy/etc' .....
And the best new 'light' I've seen in a awhile is from TI (although an infant, is their 'Pure Path Wireless Audio')
see Thd:
http://www.diyaudio.com/forums/pc-b...iy-hd-audio-intels-hdmi-hdcp.html#post2208351
Presently, the main 'limiting' factor' for HD 'server/streaming' audio is the HDMI/HDCP 'dead-end'.
Their free and open source cross-platform VLC Player and Streaming Manager is all I'd use.
Not to drag 'video' into this but their X264 group has recently announced the first free software encoder to be able to generate Blu-ray compliant video and on a std. DL DVD disk....I seriously doubted that until I burned a 'trial' they have available.....best tech comes from the free and open source rebels. They started as French students wanting to broadcast campus wide but were denied a 'broadcast permit'.
Prue 'free-will' brings us all:
VideoLAN - VLC: Free streaming and multimedia solutions for all OS!
Combine the increasing acceptance of the Matroska 'container' with it's abilities and disregard of 'file type/format/proxy/etc' .....
And the best new 'light' I've seen in a awhile is from TI (although an infant, is their 'Pure Path Wireless Audio')
see Thd:
http://www.diyaudio.com/forums/pc-b...iy-hd-audio-intels-hdmi-hdcp.html#post2208351
Presently, the main 'limiting' factor' for HD 'server/streaming' audio is the HDMI/HDCP 'dead-end'.
The squeezebox's can buffer ~20 seconds of FLAC data, so latency should never be a big deal (unless you're trying to synchronise playback between squeezeboxes - I don't have 2 hardware squeezeboxes to try it, so I'm not sure how good they actually are at that)
Hi Martin. Can you tell me what streamer you are using? I plan on one myself to go with the Vortexbox server I have built and currently the main contenders are a squeezebox duet or possibly a PS3
Thanks, Steve
Hi Steve
I (was) using a Duet. The sound compared to my CDP was slightly less attack but much more depth both in terms of real recorded space/illusionary depth of image and also stronger reproduction of lower frequencies. The overall impression was one of more realism and more effortless music - and very enjoyable.
The caveat (for me) is the setup required to run SB properly. I struggled with the system (which appeared to have glitchy software) for 5 weeks and eventually (reluctantly) returned it. I am informed it was probably a server/wifi based set-up issue but essentially the SB kept loosing my music library. Every time I re-started the computer it would have lost different data. I have rare moments where it was stable but lots more time frustratedly trying to solve issues.
I had no reservations about its playback through my system (although the amp I have is exceptionally quick and open, so I can't comment on what it will sound like with average/mass produced components - it might not shine so brightly).
I am informed that the SB server works very well when hard-wired and not using its wifi capability but this was a main attraction for me.
I am left looking for another server/system to enable the same sound...
Do try it in your home before taking this as advice. If it works for you then it is fantastic for the money.
Hope this helps - I can offer more information about my scenario but as I never solved the problems I can't offer answers🙁
I (was) using a Duet. The sound compared to my CDP was slightly less attack but much more depth both in terms of real recorded space/illusionary depth of image and also stronger reproduction of lower frequencies. The overall impression was one of more realism and more effortless music - and very enjoyable.
The caveat (for me) is the setup required to run SB properly. I struggled with the system (which appeared to have glitchy software) for 5 weeks and eventually (reluctantly) returned it. I am informed it was probably a server/wifi based set-up issue but essentially the SB kept loosing my music library. Every time I re-started the computer it would have lost different data. I have rare moments where it was stable but lots more time frustratedly trying to solve issues.
I had no reservations about its playback through my system (although the amp I have is exceptionally quick and open, so I can't comment on what it will sound like with average/mass produced components - it might not shine so brightly).
I am informed that the SB server works very well when hard-wired and not using its wifi capability but this was a main attraction for me.
I am left looking for another server/system to enable the same sound...
Do try it in your home before taking this as advice. If it works for you then it is fantastic for the money.
Hope this helps - I can offer more information about my scenario but as I never solved the problems I can't offer answers🙁
Last edited:
Martin, that is great many thanks for your reply. I am hoping to use the duet (or possibly Sonos if I can find the cash!) with my tripath / OB set up. It sounds just what I am after, your problems with it not withstanding. Again, many thanks, Steve 🙂
Served music
I looked into served music when my cd collection got into the high 100's, storage became a problem.
After much serching I came across a bit of free software called vortebox, it uses slimserver to stream, it also catalogues the cd's, you can set it up to mirror to MP3's in several bit rates,with or without cover art, it also can mirror to alac the apple lossless system.
It supports SONOS.
There is an I PHONE application IPENG which is a great way to control it all.
It has a good back up set up.
The squeezeboxes are great music clients, if quality is a concern use the digital output and let an outbord DAC do the decoding.
SUMMARY
Vortexbox (vortexbox.org) on any pentium machine makes a great server
Squeezebox makes great clients
The Sonos S5 is a great option if all in one (client,amp,speaker) is needed.
I run a Squeezebox 3 wired to a Rotel RSP 1066 via toslink as the main set up
A Squeezebox 3 w/less to a modest Denon amp via RCA (squeezebox d/codes) in bedroom.
A Duet to a DIY self turning amp in the study (duet d/codes,controls volume)
The servers sound card connected to mini system provides sound in garage/workshop.
In the two years I have been using this system the improvements in vortexbox have been many the hicups few, I cant tell the diferrence between the wired and u/wired players (my ears are old)
They sync well although not as well as a Sonos system does.
And the cd's are now out of the way.
REGARDS
I looked into served music when my cd collection got into the high 100's, storage became a problem.
After much serching I came across a bit of free software called vortebox, it uses slimserver to stream, it also catalogues the cd's, you can set it up to mirror to MP3's in several bit rates,with or without cover art, it also can mirror to alac the apple lossless system.
It supports SONOS.
There is an I PHONE application IPENG which is a great way to control it all.
It has a good back up set up.
The squeezeboxes are great music clients, if quality is a concern use the digital output and let an outbord DAC do the decoding.
SUMMARY
Vortexbox (vortexbox.org) on any pentium machine makes a great server
Squeezebox makes great clients
The Sonos S5 is a great option if all in one (client,amp,speaker) is needed.
I run a Squeezebox 3 wired to a Rotel RSP 1066 via toslink as the main set up
A Squeezebox 3 w/less to a modest Denon amp via RCA (squeezebox d/codes) in bedroom.
A Duet to a DIY self turning amp in the study (duet d/codes,controls volume)
The servers sound card connected to mini system provides sound in garage/workshop.
In the two years I have been using this system the improvements in vortexbox have been many the hicups few, I cant tell the diferrence between the wired and u/wired players (my ears are old)
They sync well although not as well as a Sonos system does.
And the cd's are now out of the way.
REGARDS
I actually restarted my wireless router while listening to music. My guess is that the process did take somewhere around 30 seconds. The squeezebox played from buffer during the restart period and reconnected to the server without any problems.
I have only flac files on the server, ~450CD's = ~140GB. I use squeezebox server.
The squeezebox can be significantly improved on by an external higher quality dac.
- Status
- Not open for further replies.