Diego

Would be basically great news, if UPnP would use "exact" error correction, using check-sums and re-transfers. Given that today's ethernet connections are fast enough to have a lot of bandwith left for re-transfers, at least when streaming 2-channel audio, even if it is uncompressed and high resolution. I hope that UPnP receiver modules as built into hifi devices really take advantage of this. This might hopefully result in more robust connections and avoid potential quality degradation due to transfer errors. Anyway, this would again raise the question, why certain testers consistently pretend to hear differences among different ethernet cables, apparently even in double blind tests, given that a word document gets over ethernet connections without any error, even through the cheapest wires. But as I wrote in my first post, I don't wont to enter into this discussion here, as there are plenty of other threads for discussing this.

My guess is, that the real-time (audio) streaming protocol has been defined in times, when the USB speed was limited in a way, that made it impossible to consider retransmissions without interrupting the audio stream. Today with USB 2.0 or even 3.0, the interface speed would not be the bottleneck anymore, so exact error detection and error correction could probably theoretically be used such as with data transfer (this is easy to guess for my as a non-technician: To transfer a sound file over the data transfer mode in USB 2.0 from one computer to another takes consistently less time than the playing time of the file, for all usable resolutions). However, to introduce a new protocol for this will probably not be considered, as the demand would be pretty low (except maybe for proprietary and therefore expensive hardware/software). Given that UPnP streaming was developed in a later stage than USB streaming (afaik), it might be possible that error correction is used just as if it was a normal LAN-file-transfer. On the other hand, the UPnP-protocol was developed with hi-resolution video in mind having to travel over a fast Ethernet or maybe maximum of n-type WiFi (as higher standards were not known yet). This makes it possible however, that the exact error correction was again traded in against transfer speed, such as with usb audio streaming. It would not surprise me, if error correction was discarded, given the fact, that most of these IT protocols are not developed with users in mind who care about the latest bit of quality, but rather the masses of users, who want streaming to work robustly, easy, "PnP", with cheap hardware, and who do not care so much about the difference between 98% and 100% of the possible reproduction quality. However, it would be nice, if somebody who knows about this for sure, could answer the question...

Hello everybody! As far as I understood the technical articles I have read about the topic up to now: USB audio protocols do not use exact error correction. E. g. if some information from the computer does not arrive at the USB DAC, the DAC fills the gap, estimating the value with an interpolation (estimated value). In this way, USB audio is different from USB data transfer, where errors are correcting be retransmission of the same data. Opposite to that, I did not find any information about the question, whether UPnP audio streaming data is error corrected by estimation (interpolation) or by retransmission. Does anybody know about this, and does anybody have a link to some reliable article to this question? Thanks! P. S. Please do not discuss in this thread the question, whether these differences between data and audio streams with regards to the error correction has an influence (or not) on the sound quality. If you are interested in this question, please refer to the numerous threads and posts where this is discussed.

Yes, as assumed conclusion of the other discussion here http://www.computeraudiophile.com/f22-networking-networked-audio-and-streaming/troubleshooting-cantata-universal-plug-dplay-player-not-recognized-ipod-or-android-control-points-resolution-audio-cantata-music-center-18320/index2.html , it was probably some issue with the dLan/powerline. I did not expect this and tested it rather late, as the dLan setup proofed to be very robust for all other network applications (including hi res audio UPnP with different renderers). Anyway, connecting my particular renderer over only ethernet as a trouble-shooting step, everything worked fine. I have not re-tested BubbleUPnP up to now, as I was quite happy as for now with MediaHouse. I will do occasionally.

I forgot to answer to Cebolla this point: Thanks for your thoughts about setting up a working environment before optimizing. However, my current setup does work now. Anyway, I want to make sure, that I avoid all potential bottlenecks that may prevent my DAC/UPnP-renderer from playing at its full potential.

Thanks for all your ideas. I am far from home these days, I'll try new solutions and report back as soon as I can. My goal remains to avoid a switch, if feasible, as "less is usually more". I prefer not to participate in the discussion about the question, whether losses over digital connections are possible or not, I just want to make my connection as direct as possible. Maybe it helps for the sound quality. Maybe it does not make any difference. Anyway, it won't hurt, I guess.

Thanks again, Coxhaus! You are indeed right, the main aim is to optimize the sound, reducing the way from the server the renderer to only one point-to-point connection, while taking advantage of the second NIC/EthernetPort installed on the server. However, controlling via a control point should remain possible. If not, the entire exercise does not really make sense. Maybe Internet Connection Sharing ICS might be a solution? This might make it possible to have a point-to-point connection over one LAN port, and the Windows 7 music server would make what is needed to connect it to the rest of the network. The other possibility is of course to connect the server over USB to the player (async), and to simply use the player as external "sound card". The next time I have time to play around, I will test which setups bring out all the sound this DAC is capable of. If USB is on the same level as UPnP, then I will then not bother around much more and have it play over USB. In this case, maybe even my current setup, using a Squeezebox Touch as "Transport" in between the server and the player (connected async with EDO) might turn out being on the same level as direct connections with the server. However, there is still potential for optimization, as the connection between the SBT and the server goes over dLan that could be avoided.

Thanks, Coxhaus! I guess you said it all... anyway, I must admit, that I probably won't be able to deal with this technical explanation. I'd need some "how to" that tells me each configuration step I need to do on Windows 7. The renderer does not need to connect to the Internet. But I want to be able to control it with the control point, that is connected via wifi to the router. And I can not hard code the ip address (gateway, etc.) on the renderer, I guess it works only with a DHCP server that assigns everything for it.

Hi had a "wireless bridge" before and dLan seemed more reliable. I will opt for ethernet, looking to make the way from the server to the MC as short as possible. Once it works with "normal" wires, I will probably go for Opal Meicord. On the question about the shortest way to connect the server to the renderer, I just opened another thread: http://www.computeraudiophile.com/f22-networking-networked-audio-and-streaming/server-connect-one-ethernet-port-directly-universal-plug-dplay-renderer-and-one-port-router-netowrk-possible-19094/#post291787

Hello fellows! I am looking for the best solution to connect my UPnP Server to the renderer. The hardware I use: - Windows 7 Pro PC 64 bit. It has two (gigabit) ethernet ports. It serves as UPnP server (with Asset server). - Resolution Audio Music Center V 2.0 as UPnP renderer. - a standard router with wifi etc. (who serves as DHCP server, too) - MediaHouse Pro as UPnP control point. What I aim: - a short connection between the server and the renderer. If possible with only one Ethernet cable. - control UPnP streaming over the wirless network The questions: 1. can I connect one Ethernet port of my PC to the general home network and use the other Ethernet port to connect the server directly to the UPnP renderer? 2. if yes: Can the router (DHCP server) access the renderer to assign the IP address? If not: can I configure Windows 7 to serve as DHCP server just on one of both Ethernet ports, just for the renderer (while being a DHCP client on the other port). And how? 3. Will the control point recognise the rendrer (that is connected directly only to the server)? Thanks for any useful help! Cheers!

I went on troubleshooting. The powerline-setup was one of the the last things to check, because it proofed to be very reliable up to now. It worked very error-proof and fast for all network enabled devices I have used it until now (video player, computers, Squeezeboxes, SBT playing uncompressed PCM at 24bit/192khz). It was usually more reliable and faster than N-type WLAN. Anyway, it turns out, that the Music Center has a problem with the Powerline LAN / PowerLAN - solution, at least in my home (there may be no problem with setups in other homes) In my home, the powerline adapters connect to each other with a speed rating of 349 Mbps - but this does not seem to be enough! Even though the MC has probably "only" a 100Mbps LAN input. I don't know why. My guess is, that the buffer-size at the MC is smaller than in other devices, and that the PowerLAN is fast overall, but the connection might suffer from interruptions, that are to long to be buffered by the MC, when it is streaming hires. I will have to buy a large Ethernet wire it seems... or a little silent nas or mini-computer to place it next to my music center with a switching hub in between. Thanks to all of you who have helped thinking!

Yea. I agree. UPnP playback over the PowerLan works fine with other renderers like foobar2000 on a PC, connected exactly at the same place to the network as the MC. However, my guess is, that the PC with foobar2000 uses more buffer than what is available on the upnp-input-hardware of the MC. And thus, the PC/foobar2000 can correct short network interruptions, whereas the MC gets interrupted when playing more buffer-consuming hi-res files. However, PowerLan has proven to be much more reliable, error-proof and fast in my setup than wireless, even "N"-type, regardless of the relatively short distances in my home. However, there may be a specific characteristic of PowerLAN that causes problems to the MC, even if it does work flawlessly with other devices (like the SBT or a PC). My next troubleshooting step will be to take the MC physically downstairs and connect it with the shortest quality ethernet wires I own directly to the router, trying with different computers as servers and, if necessary, different routers.

Just a short Update: Resolution Audio replied. They confirm, that 192khz / 24bit files work, and it has been tested for it. It should work over every interface: Also over UPnP with a NAS or a Windows PC as server. Apparently this has been confirmed on several home networks. So... I keep trying out. Maybe the problem is some kind of incompatibility issue with my router. I keep posting for those who want to know what I find out. Have a nice year full of nice music!

Update: - Tested with AIFF-Files over the same server/network setup as before. Instead of FLAC. More stability noticed. 24bit/96khz work without interruption so far. - 24bit/192khz still gets interrupted However, not yet tested with a more direct LAN connection instead of powerlan in between. This will need more time as I will have to carry around some hardware. I believe that Cantata is awfully optimized with half eaten apples in mind. That may be the reason, why AIFF-files work better than FLAC, although FLAC are probably less processor time consuming. I wonder if the Cantata has ever been tested by the developers to work with non-apple-servers and control points. However, if they declare it UPnP compliant, they really should make sure it supports the standard, not only the apple-implementations of it. I have not intention at all of buying a mac mini how they suggest on their homepage. imho this "religious" apple attachment is quite annoying. Nothing against apple - but I want to have the choice, if I buy an upnp - compliant device at this price tag.

@reverendo: You asked about my experiences with the new firmware. Here they go: UPnP tested with new firmware V 2.16 on Cantata MC. Result: No improvement so far with regards to stability. Maybe sonic improvements, but I have not tested this. As far as stability is concerned, I have the same situation as with Firmware V. 2.15: 1. Lo-res files play from a to z without problems 2. Hi-res files (tested at 24bit/96khz) often get interrupted at one point. After about 2 seconds, the music goes on playing over the speakers, but the display on the MC does not show anymore the track time, as it should. And controlling over the control points gets non-responsive. Only fix: Restart the Cantata MC. However, I start wondering, whether my network setup is not up to the needs of UPnP with the Cantata. My setup is: 1. Windows PC with Asset UPnP server 2. 1000 mbps LAN (on both sides) to Router (Cisco Linksys E3200) 3. 1000 mbps LAN to Powerline Adapter (XAV5501, rated at 500 mbps) 4. Powerline, Quality rated by Adapters at 261 mbps 5. Powerline Adapter to 100 mbps LAN 6. LAN to Cantata For the squeezebox, this network is largely enough powerful. I tested it up to 24bit / 192khz files, no problems whatsoever. Maybe UPnP (on the Cantata) uses less buffer or is otherwise more sensitive? Or is it simply, that the UPnP processor in the Cantata is not powerful enough to handle high res datatastreams? This would be quite difficult to be imagined, as it has been made especially for this... I will try figuring out, by connecting a PC with a UPnP Server by LAN (and one Switch) only to the Cantata, to figure out if it works better.