marcoc1712

Squeezelite(-R2) will always buffer only the current and the next track, so enormous buffers are not used. The golden role is to NEVER exceed the real amount of RAM available in your system, never make system paginate and swap, then use as much ram as you can.

You could use ALSA parameters for that OR Buffer size and USB profile in ASIO Drivers (in Windows), nothin special in Squeezelite-R2 (or squeezelite) here. I wrote an early version of C-3PO (and Qobuz) plugin where is possible increase and decrease the TCP socket buffer size and/or the chunk size, emulating the above in a network connection (or even a direct connection if server and client run both on the same machine). The interesting thing is that the effect is exactly the same: when you increase the latency (delay) or increase the chunk size (reducing the cycles needed to accomplish a task) you destress the CPU and the sound gets smoother. Don't know what the link between the two fact is

You could insert pregaps in the cue file for that. Marco

Squeezelite-R2 was derived directly from the Triode's last version stored in Google code, ported in GitHub and modified. Then R2 patches were applied to Daphile and Ralphy version, both started from the same version in google code, we then agreed to consider the one maintained by Ralphy the new 'standard', so he always receives my patches and updates, but is obviously up to him to apply them or not. In the "standard" version, to enable the R2 patch you need -W switch. I then Applied Daphile DSD patches to R2, with some mods, in order to play 'native' DSD, same patches are now also in the Ralphy version, with minor differences. So, R2 is the old Triode version plus R2 and Daphile DSD patches, nothing more, where "standard" includes much more that, in my opinion, is not needed. Please consider Squieezelite-R2 a sort of 'minimalistic' Squeezelite, if you like, but you could exchange it with the standard one if you like it more.

Nice to know r2 is - at least as an option - in the micro rendu, I hope C-3PO with modified SOX will follow soon.

many tanks.

Some people is claiming there is a big improovement in 3.4 version in respect of 3.3 could you tell us what is changed from a technical point of view and what do you thing is most causing the improovement? Please forgive my curiosity, but as a developer I always look forward on how to improve software and try to learn something, when possible. Thanks, Marco.

+1

Just for curiosity, Why JPlay did not (yet) move a legal action over JRiver? In the real world no one could blame another product as a "HOAX" even if it's true! Preventing current users to use the system they pay for with no option to refound, in my opinion expose JRiver to a legal action from users who bougth JRiver after using the trial with JPlay, this could eventually be defined as an "hoax". Maybe I'm wrong, but if the JPlay reaction is just looking for a technical and tricky way to elude JRiver actions, they appears to me as they feel somehow guilty.

If You were from europe You'd never said this! Don't know from where Jplay is, but since is not from Italy it smells! Not from Nothern Italy, oh God! Not from My litle town,...could not work! What? made by my neighbor, bleah... Joking, but... Marco

+1G. Sure few are going to break down walls after reading posts about standing waves and modes, just to "clear the problem at the beginning", lots are having fun playing around with any kind of tweaks on Oss... Maybe has to be said that as 1,6180 ratio and no orthogonal surfaces is 'nice to have' building a new room for music, but if your current room is not like that you could still enjoy your music in a very good way, using an optimized and dedicated computer setup for music, paired with state of the art DAC and audio equipments is a good practice, but neverless you could enjoy your music at a very good quality level using just 'decent' hardware, freeware software (maybe also OS) and good enought dacs and audio equipment. Maybe will not be audio nirvana, but sure an exciting real life experience, for somebody a starting point for others just what they will ever need about reproducing music. Then, in time, You could make thing better, meaning the computer, dac, audio gears and room. Please forgive my english. Marco

Hi, im currently using my 20 years old Audio Research DAC 1-20 feeded optical by my CD player and Squeezebox Transporter (2008), with good results, in my opinion is much better than the Transporter internal dac in every aspect but some sibilance in some rare songs. Seldom happen to me to like more the punch by the transport, but at the end I always preffer DAC 1-20 musicality. Now I would like to connect directly a Pc/Mac via USB and I wonder if the best solution is to buy a good USB/SPDIF transport to pair the AR DAC 1-20 or a completely new USB DAC, in both case I'm asking for some advise about the budget I have to deserve to preserve the actual quality (Transporter + dac 1-20) and some names. Thanks in advance. Marco.

Not to argue but to be sure I'm not missing some important point: why a dedicated music server "will" (against could) sound better than a streamer feeeding the same DAC? Is someway related to streaming tecnology? In other worlds, will (or could) a computer playing a file form a NAS sound better than the same computer playing a stream (same bitrate) from a server reading the same file on the same NAS, assuming no changes in the hw, connections and sw player, i.e. foobar2000? If so, why (the latter just curiosity). I'm a bit confused about this, please help to understand and point me to the right direction. thanks, Marco.

I Know this is a very old Thread, but I think is still interesting, at least to me. I'm a little confused by terminology used, it seems to me we call different aimed thinks with the same name, just to be clear I'll use the UPNP/DLNA 'naming skema' with a simplified views: a) The renderer(s) is the module who receive signal (stream) from the server via the network and 'play' it, just to keep it simple, let's say to the dac. b) The server is the module that 'feed' renderers, usually reading the files somewhere (internal disk, USB or NAS) and sending it (streaming) via the network. c) The controller(s) provvide the UI to manage/display the server and renders activities. d) Other than this, you have ripping, tagging, downloading and quite a lot of 'off line' (in respect of listening to music) library management, normaly perceived as 'server' activities, but not realy mandatory in this way, as far as You could rip, download and tag on other systems and move files to the server. A grey zone is where transcoding happen, in UPNP/DNLA could by both at server or renderer side. "All in one" Music server is just running all components in the same machine. Some systems like the 'original' Logitech Squeezebox ecosystems (not really UPNP/DNLA) are close to this model, other (like Apple or real UPNP/DLNA systems) could mix thinks, so your phone could be the controller, but even the server (streaming songs stored on it) and renderer, playing music from a remote server. A particular case is, from my point of view, MPD, where the server is actualy the device attached to the dac, but even if no one is really availlable today, the NAA looks to me as 'the perfect renderer' with no ability other than play music, means the transcoding take part only on the server side. From my point of wiev NAA/renderer with no transcoding is the minimal required 'real' device running a piece of software to be attached to a dac and looks to me is the piece where any effort in optimisation promise more returns in SQ, sure everything matter, so the server software and hardware, the network hardware and event the NAS could -. maybe - affect SQ, but I'm quite sure Ripple and noise from PSU, EMI, RF, vibrations,... has major effects where the asyncronous signal converts to SPDIF and some meters of CAT6 and a wall cable could well isolate... This is my personal tough, but as I understand, general audiophile feeling is not that way, and quite a lot of people state "Streamer (renderer I assume) are for casual listening, computer (all in one, I suppose) for music". Is that just becouse we have some poor streamer around (but we have also poor computers...) or there is some limit in the streaming technology i'm not aware? Dont think is becouse TCP/UPD do not grant every packet is delivered (...), since is quite the same theoretical trouble you could have using NAS and in practice is just a matter of buffer dimension. Other way to pose the same question is: the same PC reading a file from a NAS vs. playing the same file (using the same software player, i.e. foobar) via a stream received from a server will/could produce a less SQ? If so, why? p.s. I've noticied myself that some ethernet controller could cause very audible noise, but first is not a 'general' issue, then you just need it if you want use NAS for storage, so I'll prefere to keep this apart at the moment, assuming you could affectively point and solve this. Please forgive my terrible english and thanks. Marco