Re: [SlimDevices: Audiophiles] What outboard DAC do you use with Squeezebox?
simes_pep wrote: It was a John Westlake design, he was on the DIY Audio forum for a while talking about the PT products. However I'm not sure if a 24-bit stream was available when they were designed? It was predominantly a 16/44.1 feed from a CD transport/player, or a 16/48 from DAT, DCC or Mididisk. He's JohnW on pinkfish - most active on his thread re MDAC: http://www.pinkfishmedia.net/ audio forum if you want to contact him. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=72018 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
SBGK wrote: after hearing the sound quality of my nad m51 via hdmi from my laptop i am now resigned to the fact that the touch is a dead end in terms of sound quality improvements in my system. EDO is just a distraction it has higher resolution, but poor sound quality. i have not heard anything better than hdmi into the m51 via jplay xtreme for foobar2000 a real connection with the music, like listening to it for the first time. smooth, sweet, detailed just like music should sound and the sound from acoustic guitar is amazingly lifelike. nad say they use i2s over hdmi, i am inclined to believe them. anyone want to buy a MCRU 5v linear power supply and a mf vlink 192 ? comes with free fa upgraded touch in a sandwich box. HDMI done correctly [I think its hdmi 1.3 and later] will also be async - i.e. the clock in the dac and feedback messages sent to the player to adjust the playback rate to match the clock of the dac. So it has the potential to be technically better than anything with an spdif link in it such as an external usb to spdif converter as that always requires the dac to recover the clock in some way. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Display Off screensaver
Zombie wrote: Can't find the app. Is it removed? No - its still on the 3rd party list. You should look on the player Apps Gallery, 3rd Party Apps Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=95084 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Fidelizer SBT.. Why should it work?
SBGK wrote: with my large buffer settings I can get several minutes playback of 16/44.1 stored on the touch after the music has loaded via the ethernet. So I can switch off the laptop and disconnect the ethernet while the music is still playing - the sound doesn't change when I do this, it does change if I use fidelizer, that is good enough proof for me that fidelizer works. That's impressive - as you can get say 3 seconds worth of buffering from the tunable alsa buffer (usb interface), 10 seconds from the output buffer and then the main buffer (pre decoding) is 3 Mbytes in size. Several minutes would only work if you are listening to very compressed music? Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=95644 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
adamdea wrote: Leaving that to one side, have you been able to make any measurements of the S/PDIF out which could demonstrate and quantify the effect of the EDO changes (and other mods). I was surprised to read on a PFM thread a post from John Westlake saying that the S/PDIF out of the touch had very high jitter (in the nanoseconds but obviously varying between the peak to peak and the RMS figure.) I am fairly familiar with the J test which is used to measure jitter in a dac,.but i am not sure how jitter (or noise) is measured on the S/PDIF out. AFAIK such measurements are not often published either by manufacturers professional modifiers or reviewers. It strikes me that it would provide some middle ground in the current do tweaks make any difference to an external dac divide? if it could at least be shown that positive changes in the S/PDIF out could be achieved. JohnW retracted that statement later on in the PFM - http://www.pinkfishmedia.net/forum/showpost.php?p=1581854postcount=5 Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
SBGK wrote: I am still interested in understanding why the usb irq is being called 2000 times a second, is this something that can be reduced or is it dependent on the usb device used ? I don't think it can be helping sound quality. Not having interrupts would have a dramatic impact on sound quality - no sound! The ehci hardware will generate interrupts one per ms. I'm not sure if these get double counted or if there is actually two per ms, but the linux kernel doesn't change the default interrupt threshold which is to rate limit interrupts to one per ms. I'm completely missing the assertion that interrupts will impact sound quality though - this is cpu activity necessary to make the device work. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
magiccarpetride wrote: I must say I'm baffled by your posts here. Didn't you originally claim, when you announced your EDO, that your intention was ONLY to enable 24/192 processing on the Touch, and that you were certain that this mod could not possibly affect the sound quality otherwise? You seemed adamant at that point then that all the perceived differences are to be boiled down to subjective placebo and expectation bias. So why are you now engaged in discussing the possibility that there could be, after all, differences in the sound quality? What changed? Why don't you stick to your guns and let the dreamers continue dreaming? Yes... I'm baffled by my posts here :), but its why I wanted to split this discussion from the thread on the Touch forum which is about functionality not subjective impressions of sound quality. I can believe EDO impacts sounds quality, but didn't want to claim it initially exactly because of the direction this thread has taken I believe the main reason there is an impact for this for spdif is that turning off the internal dac means there is less audio related signal on the power rails (should be none!). However this also leads discussion of cpu activity related noise which can be changed by whatever processes run which is the ongoing debate here. In this second case I stand by the belief that unless the code which is executed to move audio packets around is changed in some way then I don't see it impacting sound quality. Changing things which I can show does not impact the alsa settings or the code executed to copy samples around is extremely unlikely to impact sound quality (at best it impacts the content of un-accessed memory locations!) Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
SBGK wrote: why not have the default code use the 0.6 method and then if it senses internet radio at the start of the track make it branch to a separate codepath that allow the internet radio format to play. . This is what the code is intended to do - so I want someone to prove that 0.7 is not doing this by providing a log showing different values being selected. The between the two code paths is higher up this thread, please verify this that it does nothing different unless internet radio is detected... Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
cfraser wrote: ^ lol, I forget why I even said that now. I guess it's obvious you'd need a proper/good logic analyzer to monitor an actual design. I was probably thinking along the lines of the differences between running slightly different code is sufficiently significant that it can be detected at some distance without any physical contact with the computer. Never mind close up. IOW, there ARE physical differences manifested when you run different code. This isn't an opinion (for those who don't work in the biz). Without knowing the architecture of the SBT processor etc. I couldn't even begin to guess. (I have a lot of ARM development boards here, maybe one is similar enough to give me an idea...) But I'm telling you, unless you intimately know how code/data is fetched and executed (caches?? and their operation), you can't begin to guess what effects an apparently minor code change that's logically identical to the previous code might have. Chips are designed with limitations. You exceed a limitation by (e.g.) one byte and the code may have a completely different execution signature. Rather cool to watch on the logic analyzer. You are missing the point here - we are only discussing cases where I believe there is no change to the active code being run - i.e. changes being claimed to make a difference are ignored in terms of the code running. I agree any changes to the code running could impact at least cpu/memory related noise on the power rails or ground plane. However the debate is only for the cases where there is no change to the active code running - and hence this can't be the case. In this specific case, the difference between 0.6 and 0.7 is something like: Code: resampling = false openOutputDevice() if setSampleRate() == false then closeOuputDevice() openOutputDeviceWithResampling() resampling = true end if resampling then bufferSize = FIXEDSIZE # this is the new path added and only gets reached if the device failed to set the sample rate without resampling else bufferSize = userDefinedBufferSize end setBufferSize(bufferSize) debug(alsaSettings)# print console log of active buffer settings being used Please see post #68 and my git repo for the full code. The point is that the binaries are traceable back to the code changes shown and unless you can show that the resampling case is being triggered (which we need to fix if it is), then the code is following the same path as before and this can't impact the running code. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
SBGK wrote: So basically the binaries are the same as jive_alsa for 0.6 and 0.7, just recompiled. I tried the recompiled 0.7 and it had the same issue as the old one ie harsh treble compared to 0.6, this is on a new dac so can't blame the benchmark dac1 for that. back to 0.6 and very nice it sounds to. Hope you can find a solution that keeps this sound quality. So you tried both binaries in the zip and there was a sound quality difference between them? If so can you post the alsa log output (from restarting squeezeplay using /etc/init.d/squeezeplay restart with audio.output logging set to debug) showing the difference between the active alsa configurations in each case. If there is a difference then I will happily look into this further, but if they are the same then I can't see the code causing the difference you hear. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
SBGK wrote: The outputs are all the same between 0.6 and 0.7, but I guess you knew that. So I tried 0.5 and it gave the same results, I think most people would agree that 0.5 sounds significantly different to 0.6 and 0.7, so must be down to something else. So now the change is between 0.5 and 0.6, not 0.6 and 0.7! - how does this equate to people wanting to roll back to 0.6? I'm afraid moving the comparison makes me question the assertion that there is a difference even more. However if there is consensus on this I will look at the code changes. Is there any way to stop the usb pid from changing priority to 59 ? I would prefer to have control over what priority I have processes running at. Its hard coded into the EnhancedDigitalOutputMeta.lua file which sets it - you can edit this file and restart. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
SBGK wrote: Triode, I have just confirmed to myself that 0.6 sounds different to 0.7, listening to hells bells on ac/dc back in black album the first notes from the lead guitar are particularly piercing with 0.7 and sound totally different with 0.6 - more mellow with greater depth. Look at the evidence, there are multiple different people saying they prefer 0.6 to 0.7, I don't think they are trying to create mischief, I certainly wasn't looking for a difference when I first tried 0.7, yet immediately I found it was a poorer sound to that of 0.6, I haven't been able to live with 0.7 for longer than 5 mins. I think people are genuinely trying to help and I can appreciate that it must be frustrating that such an innocuous change seems to have made a difference sonically. So are we now back to 0.6 to 0.7 being the change??? Is this shown by the difference between the two jive_alsa files in the zip file on this forum? Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
Sysagent wrote: As the title says :) How can I go back to the previous version of the EDO plugin please? I am on the current new version and to my ears it does sound quite harsh to listen to for a prolonged period of time, if somebody could post a step by step way of how to go to the previous version that allegedly did not have these traits it would be much appreciated. Many thanks, Please read the rest of this thread (at least from post #56 onwards) - although some have claimed 0.6 sounded better than 0.7, no one has stepped up to the challenge of testing the two binaries against each other and validating that they really hear a change and/or that there is a difference in the active configuration used. If you want to use an earlier version then you will need to manually install - you can find the earlier version here: http://code.google.com/p/triodeapplets/downloads/list However if you do this, please post something to this thread which verifies what has changed and how it impacts sounds quality - I don't want rumours of old versions having better sound quality to maintain without justification and evidence all future versions will be based on the current version until someone proves that something which has changed should be reverted. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
SBGK wrote: that's the problem Triode, you ask for feedback and so far you have not believed what people tell you and , in fact, have belittled the comments about 0.6 vs 0.7, why should we try your different binaries if you don't believe what people say and also if you can't hear the difference in your system. please tell us what proof will be acceptable to you. I want to find any real differences, but having posted what I believe to be the difference - which is the two binaries + the code changes, no one has tested the two back to back and provided evidence of actual changes in terms of the active configurations. Starting a rumour than version X is better than version Y just leads to uniformed people searching for an old version which we have no evidence (yet) of why they are different. The reason for being concerned about this is that many of the claims of better here and elsewhere have at least a hint of expectation bias and I remain sceptical. [Several of the changes claimed to make a difference can be shown to not impact the active configuration with only cursory review of the code and must be questioned.] Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
SBGK wrote: no point unless you want a more analogue type sound backed up by empirical testing by about 10 people. oh well, there must be some other explanation for the difference in sound caused by setting large buffers. Maybe one day we'll get to understand. Have you tried larger buffer sizes ? Please read the code (all of which is public) - unless you make a change which impacts the active buffer size all you are doing is creating an expectation of a change - there can be no difference to the actual operation if the parameters you change does not impact the active values. I'm afraid you are hitting expectation bias here... Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
magiccarpetride wrote: Actually, 'revealing system' indeed has a solid definition, so there is absolutely no need to try and relativize it and 'subjectivize' it. It is quite easy to compare two audio systems and provide quantifiable metrics as to why is one system more revealing than the other. The whole thing boils down to one aspect -- how quiet the system under study is. The noise that the system unavoidably generates while working can be measured and can be quantified, after which those metrics can be plotted and compared. So that counts out my single ended triodes with their ac heaters then... I suggest we don't turn this thread into a debate on whether its possible to measure performance differences of hifi systems using single measurement metrics though as there are many other fora for that... Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
SBGK wrote: agree that the index change is probably expectation bias, but the other changes such as buffer sizes, fab4.lua setting etc have a definite effect in my system. Changing buffer size where the actual buffer size used changes could easily have an effect. Changing it beyond the point where it no long changes the actual buffer sizes will not. As said before changing loadPriority (unless you set it so EDO is loaded later) and settings in SqueezeboxFab4.lua which are not used by EDO will not have an effect and is at best expectation bias. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
SBGK wrote: With spdif out I was using a period count of 4. Setting the buffer time to 9 gave period and buffer sizes of 1024/4096 for all sample rates. With lower buffer time the buffer size and period size would be smaller. The exact buffer cut off that allows this behaviour is somewhere between 10 and 9. Let's be clear on this - for period count of 4, with the TXRX spdif driver there is no point setting the buffer time above 10 as at 44.1 this gives a period time of 23219 which is is already limited by the buffer size. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
guidof wrote: But here is the return from the squeezeplay restart command (this with EDO 0.6, buffer at 9, period count at 16): Code: buffer_size : 4096 period_size : 256 --- lower than default period_time : 5804 --- lower than default This is interesting. I thought you were using a period count of 4. In this case the period count is so large it hits another limit (total buffer size) in the driver. This means that the period size/period time are constrained and in this case are far lower than even the default values. So with these settings you are getting a period_time of 5.8ms which is less than the default 10ms. However I also maintain you will see this with both EDO 0.6 and 0.7. For this setting you will get exactly the same active values with buffer time of 10 and a period count of 16. The limiting factor is the max buffer size which is 32k bytes or 4096k frames. So by setting the period count to 16 you are forcing the max period size to be 256 frames which is 5804us at 44.1k sample rate. In this case you will get the same values for any size of buffer time of 92864 (16*5804) and above. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
guidof wrote: When you state that my current settings force the period size to be 256 frames at 44.1 sample rate, are you suggesting any consequences other than limiting the effective buffer time to 92864? No consequences other than that - I am interested though if other settings with the same period time but smaller total buffer give any difference in your mind? Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
guidof wrote: Restarted squeezeplay with above command, which returned the following: I'm not sure this is what you wanted. If not, please let me know. See post #54 in this thread - you should see the set of alsa params which are actually used - as per the details below. The values actually used are indicated with , its my contention that you see the same thing in the two cases. If so I can't see where the difference comes from, but lets get some details of what is actually being used. Code: Hardware PCM card 0 'MXC SPDIF TX/RX' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S24_LE subformat: STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 32 buffer_size : 4096 period_size : 1024 - period_time : 23219- tstamp_mode : NONE period_step : 1 avail_min: 1024 period_event : 0 start_threshold : 1 stop_threshold : 4096 silence_threshold: 0 silence_size : 0 boundary : 1073741824 Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
SBGK wrote: Triode, this is the command that I use to check the buffer sizes, it certainly shows different values between 10, 40 and 9 For SPDIF output, TXRX device? (Yes I agree for usb, but as per post 54 I don't believe it will for spdif) Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
SBGK wrote: good point, was wondering why the EDO mods didn't get the vinyl like effect of the spdif out, but the extra detail makes up for it. So do you think 40 is the maximum value ? Read post 54 - 10 is already too big, no point making any bigger for spdif with period count of 4. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
SBGK wrote: hmm, misread your post, you are saying it does affect the buffer size for usb and not for spdif. I noticed the effect on spdif long before I tried EDO, so think there is definately an audible effect via spdif. In fact it is much more pronounced than using EDO. Think it is also having an effect because some people couldn't run with these large buffer sizes eg if they were decoding on the Touch they would get lock ups whereas if they dropped down to 3000 they didn't have any issues. if it is set to more than 9 then it gets set to -1, so that is why that value was chosen. Read post #54 - do you you see a change in the alsa params shown at startup of squeezeplay? 10 with period count of 4 is already too big for the TXRX driver. Beyond this if you believe there is an audible difference it is down to expectation bias as the software is doing nothing different and hence the only difference is in your expectation. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
SBGK wrote: have set the alsaPlaybackDevice=default in file SqueezeboxFab4.lua, this was an SBGK mod, default is 'default' As I posted above 0 this value is totally irrelevant when EDO is used - it will have no impact on sound quality. --change the permissions to allow the index parameter to be changed chmod 666 /sys/module/snd_usb_audio/parameters/index echo 0,0,0,1,0,0,0,0 /sys/module/snd_usb_audio/parameters/index I assume you are doing this after the box has booted and the usb device is attached? This is too late if your device is already attached - the index are assigned as linux boots. Also this is the first usb card so I think it will use 0 from this. If you do this and then turn your usb device on and off you will find that the usb driver is unable create a card with index 0 and so fails: Code: cannot find the slot for index 0 (range 0-3), error: -16 cannot create card instance 0 snd-usb-audio: probe of 1-1.1:1.1 failed with error -5 IN SUMMARY - NONE OF THIS WILL HAVE AN IMPACT ON SOUND QUALITY. I really suggest you read the linux sources and understand what you are changing before you claim it impacts the sound quality. Almost everything suggested recently has no chance of impacting sound quality and is the potential consequence of expectation bias... Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
SBGK wrote: To conclude, the Touch is just too noisy to live in revealing system. The EDO mod shows up the inadequacies of the spdif out, but the EDO mod introduces noise itself, not least the 2500 per second usb interrupts. I would suggest you need to be careful making blanket statements such as this. At best this is a statement of what you hear in your system and at worst its possible that you have an expectation bias of the changes (cf your assersion that EDO 0.7 and 0.6 are vastly different... or tuning buffers beyond their max value makes a difference...) I think what we can say is that in any computer based music system there may be some level of cpu activity related noise which is present on the power rail/ground plane. Whether this can be detected on the output interface will be hardware design specific and what impact this has on the downstream components will be very dependant on the construction of the downstream component. In this case it sounds like your usb-spdif device is suseptible to noise on the usb interface. Its likely than many well implemented async usb dacs may be less suseptible, others will be. However the assersion that Touch is worse than a PC is a blanket statement which I don't think you can stand by. It will depend on the PC, its operating system and specifically the output interface hardware and its power rails. There is simply too much variablity there to be able to say that it will be inheriently better or worse that Touch. As for how the touch output process influence sound quality - I suspect that the main issue here is that there is so little going on within touch that you can detect the impact of indiviual software processes/tasks on the power rails. On a generic PC there will be many more active threads and so I suspect the background cpu activity/noise is far more diffuse. However if you look at specific outputs such as usb then you will see regular interrupts which are handled by the kernel in just the same way as touch (everything uses ehci based usb chipsets for instance). There will also be application layer things which can be tuned, but the impact this has on the output will be very dependant on the hardware implementation. To summarise - I think the best you can conclude is that with your vlink 192 you can detect more noise from Touch than from your PC. I don't think this should put people off using the touch - it may mean they want to look at true asyc dacs (where there is a fixed clock is next to the D/A converter and there is no spdif/pll) Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
guidof wrote: I have done extensive comparisons of EDO 0.6 and 0.7 and for the most part agree with your impressions. Can you confirm the same is true between the two jive_alsa's files I attached (which are the same as in the two downloads) For me and with my system, EDO 0.6 + TT3.0 + SBGK's settings with buffer at 9 and period count 16 gives the best sound. By best I mean sound that is well balanced across the frequency range, detailed but rich, without too hot a treble, engaging and easy to listen to for hours a time. Quite the high-end performance from a $300 device! Please restart the squeezeplay application with: /etc/init.d/squeezeplay restart Can you confirm the actual buffer sizes this is using (see posts on this thread on what the debug which is shown the the audio device opens means) - I think you will find the period time somewhat less than 9, but I want to know if you see this being different in the two cases with the differnet jive_alsa files. (if you do I will remain skeptical that this means you can hear a difference!) Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
rgro wrote: And, Johnthat particular line is placed where? In the tcp/ip section, priorities, or kernel?? I guess my point is I think it will be hard to set nrpacks with EDO at present as you will need to change that kernel module parameter before the module detects the usb dac. As EDO assumes the dac it present at startup, so you are going to need to edit the startup scripts and then turn the dac on at the right time (after the parameter is set) - this is not going to be trivial at present... Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
cfraser wrote: It might be convenient if SBGK put some instructions on how to install older versions of EDO in his blog, like where to copy the files. You are welcome for me volunteering you. :) I don't have a blog etc. or else I'd do it. I get the impression that the instructions might not be welcome in any of the EDO threads...but I may have the wrong impression. I'm happy to have that discussion here - I can't see what changes are that would have caused differences in audio quality. Unfortunately the squeezeplay applet installer does not make it easy to install old versions of an app - it maintains a single version which will be installed for new installs so other than posting specific files for people to manually install its not easy to go back to the old version. In the case of EDO 0.6 vs 0.7 the only thing which _could_ have caused audio impact are changes in the jive_alsa binary as this is the only changed item which processes audio. However I don't believe the minor change between 0.6 and 0.7 should impact this... I'll look to build a new version with and without the last change and post here for people to test the difference. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
Ok so here's details of the difference between EDO 0.6 and 0.7 and the
two binaries for people believing there is a difference.
1st - a diff between the two install zips:
Code:
diff -dur 0.6/EnhancedDigitalOutputApplet.lua
0.7/EnhancedDigitalOutputApplet.lua
--- 0.6/EnhancedDigitalOutputApplet.lua 2012-05-15 22:20:24.0 +0100
+++ 0.7/EnhancedDigitalOutputApplet.lua 2012-05-19 15:45:10.0 +0100
@@ -251,6 +251,8 @@
{ desc = BUFFER_LARGE, time = 10, count = 4 },
{ desc = BUFFER_SMALL, time = 4000, count = 2 },
{ desc = BUFFER_RAND,time = 10, count = 104 },
+ { desc = BUFFER_VLARGE,
time =400, count = 4 },
+ { desc = BUFFER_VLRAND,
time =400, count = 104 },
}
local window = Window(text_list, menuItem.text)
local menu = SimpleMenu(menu)
Binary files 0.6/jive_alsa and 0.7/jive_alsa differ
diff -dur 0.6/strings.txt 0.7/strings.txt
--- 0.6/strings.txt 2012-05-15 22:25:54.0 +0100
+++ 0.7/strings.txt 2012-05-19 15:45:17.0 +0100
@@ -81,6 +81,12 @@
BUFFER_RAND
EN Large + Randomise CPU
+BUFFER_VLARGE
+ EN Very Large (USB Only)
+
+BUFFER_VLRAND
+ EN Very Large + Randomise CPU (USB Only)
+
REBOOTING
EN Rebooting
This shows that other than the difference in the binary file jive_alsa,
the only difference is the new menu options and the display strings for
this. If you don't select these very large buffer values then this is
not used and not relavent.
2nd the binary jive_alsa, I've just confirmed the binary builds again by
rebuilding them and the only difference is the following patch (see the
rest of the code in my github repo posted a few posts above):
Code:
--- decode_alsa_backend.c (revision 415)
+++ decode_alsa_backend.c (working copy)
@@ -628,6 +628,7 @@
snd_pcm_uframes_t size;
snd_ctl_elem_id_t *id;
snd_pcm_hw_params_t *hw_params;
+ int plug = 0;
hw_params = (snd_pcm_hw_params_t *) alloca(snd_pcm_hw_params_sizeof());
@@ -666,6 +667,7 @@
LOG_INFO(Reopening device %s in plug mode as %s, device, plug_device);
device = plug_device;
+ plug = 1;
snd_pcm_close(*pcmp);
if ((err = snd_pcm_open(pcmp, device, mode, 0)) 0) {
@@ -736,14 +738,14 @@
}
/* set buffer and period times */
- val = state-period_count;
+ val = !plug ? state-period_count : 2; // safe value when plug layer
used, else snd_pcm_close can crash
if ((err = snd_pcm_hw_params_set_periods_near(*pcmp, hw_params, val, 0))
0) {
LOG_ERROR(Unable to set period size %s, snd_strerror(err));
return err;
}
state-period_count = val;
- val = state-buffer_time;
+ val = !plug ? state-buffer_time : 2; // safe value when plug
layer used, else snd_pcm_close can crash
dir = 1;
if ((err = snd_pcm_hw_params_set_buffer_time_near(*pcmp, hw_params, val,
dir)) 0) {
LOG_ERROR(Unable to set buffer time %s, snd_strerror(err));
I've attached the two jive_alsa binaries in the zip file attached - if
you want to manually try these then scp this file them to Touch, unzip
the file and copy them one at a time to /usr/bin/jive_alsa, sync and
reboot. I think you will find they do the same thing except in the
case when you get the Reopening device %s in plug mode as %s message
in the log which is only for low sample rate internet radio stations.
In short - don't see any meaningful changes.
+---+
|Filename: jive_alsa.zip|
|Download: http://forums.slimdevices.com/attachment.php?attachmentid=13431|
+---+
Triode's Profile: http://forums.slimdevices.com/member.php?userid=17
View this thread: http://forums.slimdevices.com/showthread.php?t=94855
___
audiophiles mailing list
audiophiles@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
cfraser wrote: Things appear to be working. However, I wouldn't mind hearing how I could manually install an EDO version so that it looks (from the SBT menus) the same as if I had installed the latest EDO version by the regular method. If there is no (easy) way to do this, and if the simple manual install I did is functionally identical to doing it properly, then I guess it doesn't really matter. I'm only concerned that the manual install doesn't *look* the same, so something important may be improperly configured. Thanks. The manual install you have done is functionally the same - there is no version number in the zip file so the only time you see a version number and option to uninstall is when it is installed automatically. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
It has been reported elsewhere that sound quality of EDO 0.7 is not as good as EDO 0.6. I do not believe this to be true and wanted to confirm for users what the changes are between the two versions. There are two changes: 1) A new option on the buffer settings menu (no impact if you don't use it) 2) New code in jive_alsa which overrides the buffer setting in the case that resampling is involked. The change to the code is here: https://github.com/triode/squeezeplay/commit/198f7818c95261bf3fd14110df1004a4e7c35c9a In short I don't see a reason for people trying to install 0.6 rather than 0.7. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
It has been reported elsewhere that editting
/etc/squeezeplay/userpath/settings/SqueezeboxFab4.lua to alter buffer
tuning and output device parameters has an impact on sound quality. I
do not believe this to be true. The EDO applet is designed to run
before SqueezeboxFab4 applet and hence claims the output device. This
means that any audio related initalisation performed by SqueezeboxFab4
is ignored.
The relavent code is from squeezeplay/src/decode/decode.c - this returns
ignoring the settings if Decode: open() is called a second time.
Code:
static int decode_audio_open(lua_State *L) {
struct decode_audio_func *f = NULL;
if (decode_audio || decode_thread) {
/* already initialized */
lua_pushboolean(L, 1);
return 1;
}
Triode's Profile: http://forums.slimdevices.com/member.php?userid=17
View this thread: http://forums.slimdevices.com/showthread.php?t=94855
___
audiophiles mailing list
audiophiles@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
It has been reported elsewhere that tuning the kernel module parameter nrpacks may have an impact on sound quality with EDO when using a usb dac. This can be achieved by: echo NUMBER /sys/module/snd_usb_audio/parameters/nrpacks Please note that if you try this tuning parameter there are two things to look out for: 1) The kernel we use will limit values of nrpacks to between 1 and 20 - any values larger than 20 will be silently treated as 20 2) This parameter is only read at the time the usb audio device is created. With EDO this occurs while the kernel is booting as we need to have the device available for the squeezeplay application. I'm not convinced at present that we can effectively change this parameter with EDO in operation. I'll produce a test kernel to check this. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
Thought I'd post something to show what the maxium buffer sizes are to avoid people trying to tune too far. To see what the actual audio output setup is, login to touch and restart the application with audio.output logging set to debug: Code: # /etc/init.d/squeezeplay restart Using EDO with the spdif output, the max buffer settings are: Code: Hardware PCM card 0 'MXC SPDIF TX/RX' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S24_LE subformat: STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 32 buffer_size : 4096 period_size : 1024 period_time : 23219 tstamp_mode : NONE period_step : 1 avail_min: 1024 period_event : 0 start_threshold : 1 stop_threshold : 4096 silence_threshold: 0 silence_size : 0 boundary : 1073741824 For usb the kernel driver allows a much larger buffer size, but not this hides the fact that it is doing more work... In this case jive_alsa transfers samples the kernel which then every 1ms (full speed) or 125us (class 2 high speed) decides what to transfer over usb. So even though jive_alsa is running less frequently the kernel driver is doing more work Code: Hardware PCM card 1 'Audiolab M-DAC' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S24_3LE subformat: STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 24 buffer_size : 174760 period_size : 43690 period_time : 990702 tstamp_mode : NONE period_step : 1 avail_min: 43690 period_event : 0 start_threshold : 1 stop_threshold : 174760 silence_threshold: 0 silence_size : 0 boundary : 1431633920 Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
I promised to publish the source to the modified jive_alsa - I've put it on github as a forked version of squeezeplay: https://github.com/triode/squeezeplay This is the commit which adds the randomisation - any comments on this doing anything would be interesting, as would views on alternative algorithms... https://github.com/triode/squeezeplay/commit/dfc80a233775bdbf25a44366d4b2bbe91f08b362 Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode plugin with M-DAC
JJZolx wrote: How does jitter get through an asynchronous interface? Isn't that a bit like talking about jitter on an Ethernet connection? John is probably talking about non async usb dacs (of which there are still many) - adding an issolator to these could easliy make it worse. In the cause of the M-DAC as the designer (John Westlake) recommends trying an issolator, I think you are safe assuming the clock is reasonably well issolated from usb jitter. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94822 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
EDO 0.6 contains an experiemental menu (Settings Advanced Digital Output Buffer Tuning) to allow some simple output buffer tuning to be performed without need to install TT3 and log into Touch. I make no claim that buffer tuning will change sound quality, but did want to speculate on what changes it creates. I'm posting this here as I don't want to distract the EDO thread with speculative discussion related to sound quality tweeks... Some background to the touch software: Touch runs a real time version of the linux kernel which means its possible to define some processes as real time (run with priority as soon as they are want to access the cpu) and others which run on normal process fairness basis. The purpose of this is to be able to set the back end audio process to make sure it can also provide data to the output device avoiding dropouts due to lack of data. There are 3 main threads and 3 buffers which are relavent running within the squeezeplay software: TCP --- jive main thread - [streambuf (3M)] - jive decode thread - [output buf (10sec at 44.1)] - jive_alsa (RT) - [alsa buffer] Of these the only process which runs at real time is jive_alsa. This means it normally runs as soon as it is able to and when it runs it moves samples from the output buffer to the alsa buffer, applying volume gain and format conversion when it runs. The frequency jive_alsa wakes up at is directly determined by the alsa period_time which is defined from the alsa buffer time and the sample rate. Thus tuning the alsa buffer (aka buffer tuning) changes how frequently jive_alsa wakes up and does something. Timing of other processes running is really dependant on other things and to a first order has no relation to the output buffer size. For instance the decode process wakes up every few hundreds ms and decodes and equivalent chunk of audio data and then sleeps (once the buffers are full). So my contention is that the primary impact of buffer tuning is to change how frequenty the jive_alsa process runs and how much data it moves each time. As the process is RT it actually runs like a metronome with a very constant interval between when it starts. The interval which jive_alsa runs is the period_time which is determined by the buffer_time / period_count, with the exception that the period size can't exceed the internal alsa buffer size set by the kernel device driver. Setting the buffer time too small will result in dropouts as even with real time processing the cpu can't keep the output device dma buffer full with data. Setting it too high was also avoided by Logitech as it will more output latency which probably leads to worse synchronisation. So what does this mean: - default settings are 20ms buffer time and period count of 2 - this results in a period time of 10ms for most cases, but at 192k sample rates, the period time becomes 5.3ms as it is limited by the alsa buffer size if using the spdif output. - increasing settings to 100ms buffer time and period count of 4 results in a period time of 23ms for 44.1k, 10.6ms for 96k and 5.3ms for 192k, again limited by the device driver buffer size at higher rates A period count of 2 is the minimum which can usefully work and allows the minimum number of times jive_alsa needs to run for a given buffer time. The only real reason I can see for making the period count larger is that it allows larger effective buffers once it becomes limited by the device driver buffer size - i.e. we can have 4 or more periods each of max size which match the device driver size. What causes an impact on sound quality (if there is one?). Well I speculate that it could be the frequency at which jive_alsa runs - hence changing the buffer size impacts this. The cpu still needs to move as many bytes of data, but the process which is running at real time and hence like a metronome is running on a less frequent basis for larger buffer sizes (at lower sample rates). I don't know why this actually impacts sound quality (if it does) - it could be due to cpu related noise or noise from DRAM access coupling to other parts of the circuit, or something completely different... However there is something which definately changes which is the frequency that a bust of activity occurs. [note the size of the burst changes depending on the frequency too as the total amount of data moved is constant] EDO 0.6 includes a simple way to try the default buffer settings + large (buffer time 100ms, period count 4) and small (buffer time 4ms, period count 2) via a simple menu option - which will then reboot when selected. It also includes an option called large + randomise cpu - this still runs the jive_alsa process at real time, but attempts to randomise when jive_alsa wakes up. This is a total experiement to see if it has any impact... What it does is schedule the next time it should wake to be the time until the output buffer can accept a period's worth of data + between 0 and 90% of additional
Re: [SlimDevices: Audiophiles] Display Off screensaver
rgro wrote: Hi Triode, Just to clarify, am I correct in that for your app to function when music is playing, the Display Off option should be selected under ScreensaversWhen Playing? Thanks, Yes, and probably set the timeout to 10 seconds. After the 10 seconds timeout, this will cause the screen to blank by turning off the backlight and disabling the display in the same was as TT3 and also stopping the render of the screen which happens within the squeezeplay application. The later means than if the display would have shown scrolling text then it will not be updated taking cpu time even though you can't see it. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=95084 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Display Off screensaver
lake_eleven wrote: Once turned off, how to turn on if needed? By touching the screen or using the remote control - it acts as any other screensaver in that it only triggers after a timeout on inactivity. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=95084 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Display Off screensaver
Covenant wrote: Triode wrote: I will post this here as its clearly unproven and something to discuss on the audiophile board [As an aside - I note that with the EDO app installed and the internal digital out selected so that the analog output is not enabled, if you measure the analog outputs on an oscillocope then you see a much lower noise floor than when the analog dac is enabled. Does this explain why so many of us report an improvement in SQ using 16/44 material? The lower noise floor at the analog output is only because the dac is not running - which looks to generate quite a lot of low level noise for 0 output. When it is turned off then this is much lower. However I think the impact could be more significant in that with the dac on at full volume then the power rails are not only powering the dac but also seeing some level of signal related variation. With the dac off this is not there and there should be direct no audio signal related modulation on the power rails. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=95084 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Display Off screensaver
lake_eleven wrote: Can this be installed over EDO and TT3.0 Yes, but not the screen off part of TT3 as it is intended to to that function (and slightly more) tied to the screensaver activation. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=95084 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
[SlimDevices: Audiophiles] Display Off screensaver
I will post this here as its clearly unproven and something to discuss on the audiophile board I've just posted a new app to the repro for Squeezebox Touch - this provides an alternative to the built in Screen Off screensaver which disables some of the processing associated with the screen when the screen is off. It does the same as TT screen off + also disables some internals to the squeezeplay application related to rendering the screen when it is off (reducing cpu load for scrolling text etc when the screen is off). The intention is you may want to try it as a when playing screensaver which will bank the screen after the delay and hence use less cpu power. Whether this has an impact on the audio quality is unproven and the reason I am posting here... To install: On the player goto 3rd Party Apps, unselect recommended Apps only and then select Display Off [As an aside - I note that with the EDO app installed and the internal digital out selected so that the analog output is not enabled, if you measure the analog outputs on an oscillocope then you see a much lower noise floor than when the analog dac is enabled. At the limit of my simple scope's gain I can see noise which is related to cpu activity - I believe looking at this, that disabling the screen does have a measurable impact, but it is very much at the limit of what I can see and well below the normal noise floor of the analog output. Whether this impacts what you can hear is a completely different matter] Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=95084 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
tonyptony wrote: Does anyone know if Inguz uses the alsa plugin layer or the jive_alsa process? It would be unfortunate if this interesting new app is not able to run with Inguz in line. I'll have to try it out and see. Inguz is all server side and this is all done on the Touch player so don't see why they can't coexist. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
There has been some discussion on the Touch forum about the EDO app and the potential benfits to audio quality from the spdif output at 96k and below. This is not the primary purpose of the enhanced digital ouput app but people have debated whether any possible change in audio quality exists. I throught it would be useful to spell out what the changes are that are in EDO. As I may speculate about any impact on sound quality, I thought I'd do it here as its definately a discussion for the audiophile forum. EDO essentially comprises three parts: 1) A custom linux kernel which is the standard Logitech kernel with the following changes: - spdif - additional clock divider values to allow 176.4/192k playback - usb scheduler - minor changes including change of default compilation options to allow most dacs to connect to usb - usb audio - major changes to include most of the more recent linux kernel changes that support uac2 - experimental alternative kernel idle routine 2) A squeezeplay applet which allows the kernel to be installed and provides menus to select the output device. It also starts up the audio output of squeezeplay and uses does a couple of things differently from standard squeezeplay: - it does not start an effects jive_alsa process (it is assumed users don't want to hear the effects processing) - it bypasses the alsa plug layer and uses the spdif output TXRX directly, simplifying the amout of processing required between jive_alsa and the spdif output driver - increases the priority of the irq task associated with the spdif driver (primarily to improve performance for 192k playback) 3) A new jive_alsa binary which adds support for additional alsa formats for packing samples into asla frames - this is necessary for the usb dac support, but there are no changes which I believe would impact spdif. Now I don't claim sound quality improvements from any of these for spdif playback and I have not done any critical listening for this. I would also not want to make any claims without being able to measure the circuit in more detail. However you could speculate about the following: - not sending output to the analog will avoid there being any data sent to the internal dac and avoid any data related load on this part of the circuit/psu - bypassing the alsa plug layer will reduce cpu load - not having a second jive_alsa process running reduces cpu load slightly However all these could be achieved with TT3 (I don't run it, but reading the code it looks like it will do this and much more) So its probably best to see EDO as doing the more obvious bits of TT3 to me. There is one other component of the app which is dissabled by default and is a complete experiement - this is the kernel idle option. This can be turned on from Settings Advanced Digital Output. What it does is subsitute the default kernel idle task (which allows the cpu to enter low power mode) for an alternative one (which does not enter low power mode). I speculate that if cpu load has an impact on sound quality then this should have an impact less than 100% cpu means the idle task is being run. I would be very interested if people can tell the difference with it enabled or not Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Triode's USB 24/192 plug in - sound quality impressions
JohnSwenson wrote: I have a HRT Music StreamerII (not the +), it works very well with Triodes plugin and a hub. Adding TT3.0 significantly improves the sound, with this combination it's getting astonishingly good. (it's not the best, my homebuilt DAC still blows it away). The II with TT3.0 is sounding better than several other way more expensive S/PDIF input DACs I have. (except for my own design -- I'm not biased am I?) I had to do a little work to get TT3.0 to work with it, I had to set the buffer to over 5000, and I had to change some of the priority settings. The esiest way to change the priorities was to just turn them off all together. I didn't have time to figure out which one caused a problem. I tested the screen off part of TT3.0 and it didn't make any difference so I left the screen on. The part of TT3.0 that seemed to make the difference was the kernal settings, when I implemented just them I got the same sound improvement. John S. Note that the app changes how the buffer setting is defined - so you will need to edit the EnhancedDigitalOutputMeta.lua rather than the standard file to change buffer setting. I'm interested if the kernel idle option makes any difference wrt to the kernel tuning? Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94855 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Digital transport/TT 3.0 explanation revisited, please
Soulkeeper;698674 Wrote: Can you please elaborate on ASRC? What is it? (async clock recovery? adaptive clock recovery something? if so, what is that and how does it work, can you point me to some resources?) Asynchronous Sample Rate Converter - try the thread on diyaudio: http://www.diyaudio.com/forums/digital-source/28814-asynchronous-sample-rate-conversion.html -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=94352 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] 192 downsampling when decoding at server side
JohnSwenson;694826 Wrote: Actually I was thinking more about code than data. The assumption being that a mainloop for processing PCM is probably a lot simpler than the loop for processing flac, thus giving a higher probability of a cache miss on the code. I haven't actually analyzed the code or run them through a processor simulator etc so I don't know for sure. In a couple weeks I will have my new groundplane noise analyzer up and running and I will be able to tell if there really is a difference there. I'm interested in people hearing this difference verses the difference of running the background process which is part of my blind tester app. As I said in that thread I can see the amount of time and frequency of running the idle process causing differences in power consumption of the cpu, but thus far I think there are any results showing this... -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=93970 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Data Rate Kbps
Assuming you are testing to a classic player then I think the difference is likely to be some changes to the firmware which slowed down the maximum rate that network test would run at. So I agree its not as accurate now as it used to be (unfortunately). In contrast network test on squeezeplay players should be more accurate in recent builds. -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=93879 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] soundcheck's Touch Toolbox 3.0
Soundman;690874 Wrote: As I already said: The only TT-mod that works without rebooting is tt -k, which by itself doesen't make a big difference. But for me it's not so important anymore to make more tests, because my friends and myself (five people) did a blind-test and all five were able to identify the Touch with the TT-mods (accuracy was above 95%). And all the five of us concluded, that the Touch sounds better with Soundcheck's mods. Why sould I do more tests, since I'm very happy with my modded Touch? Klaus did a very good job indeed! I am very happy to accept that the Soundcheck mods create an improvement - I'm interested in why and how we can improve further The app is intended to help discover this and see if any further mods could be beneficial. I am interested in results from people who have a system which shows the differece between mods to see what their results for test 2 are. -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=91322 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] soundcheck's Touch Toolbox 3.0
Soundman;690607 Wrote: It's not suitable to test TT-mods. As Triode writes: The applet only supports changes which can be made on the fly without restarting Touch. The TT-mods always require a restart (except for TT -k). Comes to it that the TT-mods should be tested all together, which is not possible with Triode's app. But it's the sum of all of them which really makes the difference. I think some of the TT mods can be made to work with the approach in the blind tester, others which require a reboot can't easily though I am willing to consider extending the app so state it persits across reboots. However I do think its a valuable way to understand changes whether its a batch of them or individually. The included test set does also make a change which I would be interested in people's observation of... -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=91322 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Spotify sound quality
squeezophile;582034 Wrote: Would volume leveling settings in the Spotify menu affect the sound quality? I mean, I read that reducing the volume on the squeeze box results i a lower quality on the digital out because of the reduction of resolution when decoding. see: http://forums.slimdevices.com/showthread.php?t=77725highlight=volume+resolution After comparing some tracks on Spotify I noticed that some tracks are indeed better than others. I doubt that the volume leveling value for the desktop client is used by the library, though I can't be sure. Sometimes you will get a 160k file rather than 320 - you can often see this if you have logging for the helper app set to debug. Other than setting a preference for 320k, there are no api calls to influence sound quality. -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=82484 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Bit perfect SqueezePlay and WASAPI support?
I think the latest version of portaudio supports WASAPI - I've not tried though. Another reason to look at this though... -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=76025 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] BBC - higher bit rate
The BBCiPlayer plugin uses the new 96 kbit/s live streams if you are in the uk. -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=45881 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Design miss in SB3 digital output? or Slimserver problem ?
Anyone wanting to understand the slim architecture more and the impact of powering off and on the player could try turning on the d_slimproto_v debugging and looking at the lines which starts sending. This shows all the control frames sent from the server the player. You will see that the difference between pausing and unpausing a track and pausing, powering off, powering on and unpausing is minimal - just a few different grfe (graphic i.e. display frames). This is the reason for the arguement that nothing special is happening by powering off... -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=36503 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: Buffering on the SB3
I was trying to say its much more than 50ms - its of the order of 10secs or more depending on the data rate you are streaming at. [put I liked to do demos which always worked] -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=32248 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: Buffering on the SB3
Buffer size is implemented in the player firmware and is not user adjustable I'm afraid. -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=32248 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: ok, may be i am just crazy, but how can i be so lucky
PhilNYC;171712 Wrote: I'm not saying that the file is jittery. But when you play an Apple Lossless file on a Slim Devices system, SlimServer converts that Apple Lossless file into FLAC/WAV on-the-fly (as you put it)...and that is where I am saying that perhaps some jitter is being introduced. The timing accuracy of that on-the-fly conversion will be dependent on the local oscillator of the CPU that is doing the conversion... Slimserver converts the files as fast as the server can run, there is no clock involved in this process it takes X bits of format 1 and turns them into Y bits of format 2. If the server is fast it runs fast, if it is slower it takes more cpu time. But critically this is a bits only operation, there is no timing involved. The clock and potentially jitter is only introduced when you reconstruct the signal in real time which is only done in the player. -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=31833 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: why didn't cd players ever re-buffer?
audioengr;147864 Wrote: My point is that the buffer that is doing the decoding of the bits on the disk is clocked by the PLL clock that is influenced by the jitter on the disk. The clock that clocks the buffer input is identical to the clock that clocks the buffers output. It is one PLL clock and it gets jittery from the variable spacing of the bits on the disk. This buffer is only a holding place in order to decode the bits. It is NOT an elastic buffer for reclocking the bits. Out of interest I've just looked up the datasheet for the Sony cdx2500bx which is used as the cd cdcoder in my aging transport (Teac T1). This claims 32K of RAM for wide-frame jitter margin (+-28 frames). No matter how you look at it, if there is one PLL and it must track the bit-rate coming off the disk, then it will be affected to some extent by the jitter in the pits and motor speed-variation, loop-control, mechanical resonance of the disk spinning etc... So in the case of adding a Superclock to improve performance - do we replace the PLL clock with a fixed phase clock? I'm struggling to understand how that avoids compromising the data. -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=28621 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: Transporter as external DAC - which cable?
Depends what you mean by network cable. Old ethernet cable and much lab stuff is 50 ohm characteristic impedance. Patch cables used for telco transmission links [1.5M, 2M, 34M, 45M etc] is 75 ohm. The bnc connectors should match the cable impedance - normally the 75 ohm ones don't have insulation around the earth connection - see here (thanks to google!): http://sosnick.uchicago.edu/BNC_50_75.html -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=28701 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: Transporter analog out questions
gharris999;140139 Wrote: 2). What is the best way to unbalance the Transporter's XLR analog outs to connect to unbalanced RCA ins on the ATI amp? (I assume that a LoZ to HiZ transformer is NOT the way to go.) Note that doing this may not sound the same as using the unbalanced output from Transporter. The Dac chip has balanced output signals and in this configuration you are only using one of them. This potentially removing some of the benefits of differential output from the dac. The unbalanced output combines the differential outputs and so is a true unbalanced output. -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=27946 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: 1K Balanced impedance
I'd have thought what mattered is the low pass filter break point formed by the output stage/input stage [resistive] impedance and the cables [capcitance] impedance (plus any input capacitance of the power amp). Even if the output stage impedance = input stage impedance as long as the LPF break point is high enough should be OK. Hence a passive pre with a 100K pot has a max ouput impedance of 25K [pot in the middle]. If this drives a cable of say 100pF/m - gives a -3dB point of 64kHz for a 1m cable, but 6kHz for a 10m cable. [You probably want much less than -3dB at 20-30K] So 1K should be fine as long as the cable capacitance is low enough - i.e. it is a relatively short enough. So if the target LPF break point is -0.1dB at 20kHz, it is -3dB at ~130kHz, which would equate to ~12m for my theoretical 100pF/m cable if I have done the maths right(!) [input impedance 1K] -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=27445 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: Is max volume really max?
Good to hear this John. You will be glad to know that following some debate, 6.5 will default to replaygain turned off for new players - so audiophiles should not get tripped over by this in future... -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=26002 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: 12.28Mhz oscillator removal - which radio streams will I lose?
Should be OK with alien as the mplayer config resamples it to 44.1. Also, all you need to do is lift one end, so it is can be restored if necessary.. -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=25265 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: letter to Hi Fi News
People worried about the different processing being performed by the cpu for flac vs wav may like to consider the impact of repeating bit patters in the digital stream. Surely it would all sound better if the data being processed exibited no repeating patterns which could be coupled into the power rails -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=25138 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: Replaygain affecting sound quality?
Back to something mentioned higher up this thread. What do people think of a SmartII replay gain mode - which only uses track gain and if it detects multiple tracks from an album it defaults to 0db. My ideal (from an audiophile point of view) would be to use track gain when playing a random mix and 0 db all other times. However having looked at the server code this is harder to achieve - so is the suggestion above useful? If so can someone raise an enhancement request and note it here?? -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=18948 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: SB3 rave in Stereophile March eNewsletter
Anyone deeply interested in spdif/jitter etc from an engineering perspective may be interested in a couple of recent threads on diyhifi: http://www.diyhifi.org/forums/viewtopic.php?t=432 http://www.diyhifi.org/forums/viewtopic.php?t=453 One of the thoughts coming out of this is that spdif actually has significantly lower jitter than the recently hyped usb. However spdif from a CD transport contains regular subcode data which is not present on usb and this potentially adversely impacts the dac. Sean - what do you put in the subscode bits? [Don't suppose your new toy will be able to do the equivalent plots?] -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=22301 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: SB3 rave in Stereophile March eNewsletter
Skunk Wrote: CS8412 doesn't, but CS8411 has a built in buffer. The CS8412 uses a on-chip PLL to recover sender clock data. I seem to recall Sean saying the programmable PLL chip (not sure if it's on the receiver chip or seperate) is part of the key to SB2/3's low jitter, along with other things. There are no PLLs in SB2/SB3 for the audio chain [this is a reason why it sounds better than SB1 which had a PLL for the master clock for the 3rd part chip used.] Indeed it has separate crystal oscillators for 44.1 and 48 KHz, specifically to allow this and support multiple sampling frequencies [compare this to certain other computer based products with don't] CS8412 has a single sample buffer, CS8411 buffers a small number of samples. Key point is that they both support 2 modes: 1) output clocked by recovery of clock from the spdif line 2) output clocked by local clock in the DAC In the first case, the internal PLL recovers the clock from the spdif datastream and is used to clock out the data - hence samples are clocked out at the rate they are arriving. In local clock mode, the local clock can run faster/slower than the clock generating the data. In this case either chip will drop or insert a sample. Now the issue that has been learnt over time is that jitter on the conversion clock at the DAC chip is much more noticable than people originally thought. Essentially the issue is that the correct samples reproduced at slightly the wrong instance in time results in distortion which is audible (arguably as bad as slightly the wrong sample reproduced at the correct instance in time) Hence to get the best reproduction you really want a low jitter clock directly connected to the dac chip as this is what is doing the digital to analogue conversion. A crystal oscillator is always going to be lower jitter than a non crystal based PLL - which is essentially a guessing circuit [create a clock, compare it to the incoming one and change it a bit if it is going to fast or too slow] Two box systems which use DACs are hamstrung by spdif as it was designed prior to knowledge of the jitter issue and so make it difficult to extract a precise clock from the data signal due to both the data and clock being encoded together. Hence a PLL is needed to extract data at the receiver chip in the DAC box. Recent dacs have attempted to address this in multiple ways, e.g: 1) Asychronous clocking [just run the DAC with its own clock, make no attempt to sychronise the two and put up with the occasional sample being dropped or repeated on the basis that such errors are less audibly noticable than jitter on the clock] e.g. DDDAC diy dacs (http://www.dddac.de/) 2) Crystal based PLL (VCXO) which is able to produce a low jitter version of the recovered clock as it is based on a crystal oscillator. Note there is no need for a large buffer to do this as as the jitter between the input clock and the conversion clock only equates to fractions of a sample time. E.g. Tentlabs XO-DAC (technical background: http://members.chello.nl/%7em.heijligers/DAChtml/PLL/PLL1.htm) 3) Asychronous resampling - resample the data in the dac to a new sampling rate defined by a local low jitter crystal based oscillator and then use this to clock the dac chip for conversion. This uses an asychronous resampler chip which actually creates new sample values to represent the data at a new data rate. The conversion chip is really doing some clever math to convert between sample values and so is able to absorb an amount of jitter on the input stream as it can assume the input samples were produced at a fixed rate (it does not need them to turn up at exactly this rate). The upside is that the jitter at the conversion chip is low, but the actual sample values are changed as the sampling rate is changed. Now SB2/3 is a one box system so it gets excellent quality for level of the components used by using a low jitter crystal oscillator and connecting this direct to the dac chip without the need for an spdif link. When an external dac is used, as spdif has to be used the questions over how the clock is recovered in the dac and used to clock the D/A conversion all apply... -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=22301 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: SB3 rave in Stereophile March eNewsletter
cliveb Wrote: The buffer isn't in the DAC, it's in the transport. *All* CD players and transports, since day one, have such a buffer. It's as essential to the correct operation of a CD transport as the laser itself. Agreed - the datasheet for the sony cxd2500 in my transport [very common chip a few years ago] includes: Wide-frame jitter margin built-in 32K RAM. This is needed to buffer the datastream from variations in rate of reading the disc and allow a cheap motor + servo to manage its speed. -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=22301 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: SB1 digital out compared to SB2 and SB3
FlyFishAndGolf Wrote: The studies published by the Audio Engineering Society demonstrated that jitter isn't audible until around 20,000 ps. I am also of the opinion that the entire jitter problem was overhyped by marketers. Figure 9 of http://www.nanophon.com/audio/jitter92.pdf (also an AES paper) suggests audibility of jitter goes much lower than 20ns... -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=18116 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: Anyone have this kind of setup with lossless files?
I can stream lossless to SB1 overwireless fine. In this case slimserver is actually sending either uncompressed wav or mp3 (if bitrate limiting is set for the player). Do you have bitrate limiting set? You don't say how this is wired up - are both hops wireless? With SB1, there is a relavely small buffer on the player (when playing uncompressed). This means the server needs to respond rapidly to requests for new data. The server does not cache any input data when serving what it thinks are local files. If the file are on a network server and the server is slow responding, this could potentially cause it to slow down reading the file. This may be your problem. Have you tried running slimserver on the server machine itself (as then the files are local and slimserver can access them imediately). -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=19286 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: SB1 digital out compared to SB2 and SB3
I think this really depends on your dac. I can tell the difference between different transports. But then my dac has a simple spdif input receiver [very common crystal 8412] with standard loopfilter - this only attenuates jitter above 25Khz. Adding a new clock to an old cd transport was noticable with this. More complex dacs attenuate jitter much more (in the digital domain using async resampling or by secondary plls with much tighter loop filters). With these any jitter on the spdif line should be much less noticable... -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=18116 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: Signal Strength -- Ideal
If you think you are having wireless problems, I have just posted a new plugin which tries to measure the wireless bandwidth between slimserver and the player - which should be a more useful metric than signal strength. I'd welcome feedback from people having difficulty with wireless as this was the reason for writing the plugin. The plugin is attached to post 37 of the following thread: http://forums.slimdevices.com/showthread.php?t=16832page=4 It is designed for server 6.2 or later. To use, unzip the file, put the resulting NetTest.pm into the Plugins directory of your slimserver [C:\Program Files\SlimServer\server\Plugins or equivalent]. Restart the server. A new menu item should appear on the player Plugin menu Network Test. Navigate to this. Then press the down button to choose a data rate at which to test. The player should then display the data rate and the %age of packets which get through at this rate. The bar graph on the right and first percentage measure the last second period. The second percentage is the average over the whole test at this rate. To get good performance you should be seeing 100% at the highest data rate you want to stream files at. [e.g. flac ~1000 kbps] -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=18199 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: SB1 digital out compared to SB2 and SB3
From that description it sounds like a relatively simple input circuit (nothing wrong with that). I would expect it will work fine with SB1 or SB2/3, but as it does not include any internal jitter rejection, the SB2/3 will potentially sound better. -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=18116 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: SB1 digital out compared to SB2 and SB3
I think this depends on your dac, what it does to reduce jitter and if it is fussy about the frequency of the digital signal. SB1 used an integrated chip to do the dsp functions and produce the spdif output. This had a known limitation that the exact frequency it produced could be slightly off 44.1 KHz and given that the chip vendor was unwilling to fix it, slim had no control over it. This is no cause for concern for the vast majority of dac users, but did impact some as their external dac was unable to lock onto the signal. There were also some reports of channels swapping over in SB1 due to the operation of the dsp chip. The dsp chip in SB1 also used a PLL to derive the clock used for the digital out. This means that the jitter on this clock is higher than that which would be obtained with a direct crystal based oscillator. SB2/3 should have all of this solved - the spdif output is generated directly from a crystal oscillator with no PLL. There are two separate crystals for 44.1 and 48 KHz sampling. So what does this mean, I would suggest: 1) If you dac is not fussy about the exact frequency of the digital input (does not experience 'lock' problems) and has internal circitry to reduce jitter, then you may not hear any benefit from SB2/3. 2) If however your dac is fussy about locking or does not have strong jitter rejection, then the SB2/3 is likely give better performance. The one hardware change between SB3 and SB2 will also be beneficial as it should further reduce the jitter on the digital output. In short SB3 (and 2) is definately technically better for the digital output than SB1. Whether you can hear this depends on how well your external dac hides the influence of jitter from the transport. -- Triode Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=18116 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: 88.2/96khz upsample w/SB2 internal DAC possible?
There is a school of thought that upsampling in software means you can build more accurate digital filters etc... See some discussion at: http://db.audioasylum.com/cgi/m.mpl?forum=pcaudion=4690highlight=secret+rabbitr=session= Having played with this foobar upsampler, it can eat most of the CPU cycles on my PC, but does make some 'difference' via the RME sound card in my 2G Athlon PC - [NB I'm not claiming it is better!] Hence the more complex functions aren't realistic for a SB2 type device in software, but could be an option for server side upsampling if the rest of the chain could do 24/96. -- Triode ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: Re-boxing SB2
Andrew, Any views on the noise spectrum of Nicads/NMHi batteries? I am speculating about a battery psu for the HCU04. As I am only interested in digital out I am wondering whether this is a way to go. I'm Currently using a simple linear reg for this. Adrian -- Triode ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: Re-boxing SB2
Sean - any chance you could confirm the family of the Xilinx chip. I just want to check it doesn't have any problems with input voltages above 3.3V (should be fine if interfaces to 5V or 3.3 V logic which I think it does based on the datasheets I've looked at) The thing I want to try is is 3x 1.2V cells to the HCU04 -- Triode ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: Getting the best from PC audio
I think the RME analogue output will always be limited in comparison with a high end external dac - but you probably want to try whatever you are considering out as you need to get into the region where you are spending reasonable amounts of money on the dac to improve. I think there were some posts on the http://www6.head-fi.org/ computers as sources forum about modded RMEs and DAC1s - I think the conclusion was that the DAC1 was preferred. [Though I have never heard one myself and would want to before buying] -- Triode ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: Getting the best from PC audio
Re 2 - I doubt you will think SB2 internal dac is better than the RME - I think you will be looking at an external dac to get a significant improvement. SB2 would clearly be an option for this, but the RME also has a good output [it should at the price - you could get a wired and a wireless SB2 for the RME price] I rather like my RME as it gives me quality sound from my work room, but do serious listening from an external dac connected to SB2 or CD tranport, but only as the RME is in a different room. You may want to try the foobar secret rabit resampling stuff with the RME mentioned on AA's computer audio asylum [but I see you posted there too!] Adrian -- Triode ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: Super regulator measurements
Sean, Interesting - I take this as official sanction to discuss SB2 mods on this forum... I'm most interested in spdif output mods and would be interested in what you have been considering. Experience moding my CD transport has lead me to the conclusion that jitter does matter and the psu for at least the clock is critical... [at least into a DAC with minimal jitter reduction] Quick question: other than not playing 48K sampled stuff, would removing the 12MHz clock cause any issues [does any logic rely on it oscillating?] On my CD transport I also found benefit reclocking the spdif line with a flipflop just before the output buffer. Is the output of your Xilinx clocked anyway to avoid any benefit of this? Adrian -- Triode ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: FLAC onboard decoding v. server side in SB2
The theory being that the microprocessor executes sufficiently different instructions between decompressing flac and wav to impact the psu in a way that impacts the rest of the player? I believe the processor uses a 1.6V rail and the oscillator impacting jitter is 3.3V so there is little chance of this [even if we believed the first assersion] Now if this thread had been about the visualizer or scrolling text impacting the sound quality then it would be more interesting [withdrawing quietly to see if this sparks some more comparison threads...] -- Triode ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
