I feel it's important to make a clear distinction between file transfer and buffering that happens pre-player and includes error checking protocols and can be assumed to be 100% accurate unless there are latency issues, which a sufficient local ram buffer should easily take care of and data transfer and buffering which is happening in the audio domain post-player, has no method for error checking and can be subject to degraded signals, timing issues and such.
I don't think the 2 are directly compatible. They are not subject to the same issues or affected by the same changes and improvements.
I don't think the 2 are directly compatible. They are not subject to the same issues or affected by the same changes and improvements.
Please note tests were carried out back in the days without S03. Tests were done on the Raspberry Pi with direct i2s to DDDAC.
This is from worse to best:
1. PiCorePlayer, laptop with LMS loaded. NAS was LAN to Router, both Pi and Laptop were also LAN to same router.
2. PiCorePlayer, laptop with LMS loaded. Pi and Laptop were also LAN to same router. Source was stored with laptop on second HDD.
3. RuneAudio, NAS was LAN to router, Pi was also LAN to router.
4. RuneAudio, Pi was LAN to router. Usb spin HDD with stock ps.
5. RuneAudio, Pi was on USB extension cable with USB wifi dongle to router. USB Spin HDD powered by linear ps.
6. RuneAudio, Pi was on USB extension cable with USB wifi dongle to router. USB SSD powered by linear ps. No audible differences were detectable between SSD and USB Flash-drive.
I agreed with Linuxfan that each audio setup has its own synergy, each audience hearing is unique, and among zillions others...!
In the interest of constructive community, can someone please carry out the similar tests and report back?!
Thanks Chan, that's great, and this mirrors my own experience with finding improvements going from wired Ethernet to wifi on a USB extension cable.
But... as with your example, I also had no Isolator between rPi and dac when I was using Ethernet and when I experimented a little, I found that I was inputting mains noise from my Ethernet power plug straight into the sensitive gnd of the DAC.
So for me too, wifi did sound better, but not because it was inherently more accurate, just because the Ethernet brought other physical issues.
So I do accept that there can be an ultimate sound output difference between these file delivery methods, but I surmise that these differences are the result of physical issues.
My guess is that wifi on a USB extension or a large, low power solid state drive will be best as these bring the least of these physical issues into play. No extra power supplies and motors inside the case, no physical wire connection to other electronic devices etc.
And I'm not ignoring your request for more testing, but my kit is in bits at the moment so it's hard to compare just now 🙂
Thanks,
James
Chanh, thanks for your detailed reporting.
I want to clarify how/where the storage drive was connected in setup 4, 5, and 6 please.
Do you mean that your hard-drive/SSD/flash drive was connected via USB to the router, or to the Pi?
I want to clarify how/where the storage drive was connected in setup 4, 5, and 6 please.
Do you mean that your hard-drive/SSD/flash drive was connected via USB to the router, or to the Pi?
I bought the NAS purely for audio, it has four 4TB WD Red. Now collecting dusts!
Setup 4,5, and 6 with all flac/wav files stored in appropriate drive which usb connected direct to the Pi.
Thanks for the details, quite a revelation but also note that downstream processing using buffers, isolators and reclockers were also meant to mitigate the effects of upstream timing issues. So at some stage you may try to pare back and see if this is really the case, now that the S03-BBB is in place. I may be wrong but there could be no audible difference in the sound quality whichever way bit-perfect music is served from the upper layers.....
Last edited:
This morning I ran an experiment; I copied a couple of tracks onto the BBB and used the local 'play' function to compare the result with the same tracks hosted on network storage and played in my normal way using a UPnP controller.
Everything else was identical. I listened using headphones as I've done a lot of listening that way since finishing my build and it has proved capable of revealing subtle details in music that I haven't heard before. For those who haven't seen my previous posts, the renderer/dac configuration consists of;
BBB > SO3 >Buffalo DAC IIIse > Legato (All in sync mode, clocked from the SO3. Power provided by Salas shunt regs)
The tracks sounded the same to me.
Possible conclusions include:
1. I have cloth ears
2. My setup doesn't have sufficient resolution to reveal any differences
3. There are no differences
Make of it what you will. Personally, I really like the convenience of the network-based solution and it feels as though I can continue to use that without feeling that by doing so I'm short-changing myself.2. My setup doesn't have sufficient resolution to reveal any differences
3. There are no differences
On a more general note, I've put a lot more hours on the renderer over the last weeks and I remain delighted with its performance. It may be my imagination but I'm sure that it has continued to subtly improve, the music just seems to be more organic.
I haven't tried any experimentation with the DAC switch settings yet. I've been reflecting on the suggestion to remove the clock dividers and run the BBB at full speed; I have to say I'm disinclined to attempt anything that risks damage to the SO3 (with my eyes and soldering skills attempting anything involving smd components is risky!) especially as it sounds so good and the experiment above suggests that the SO3 could be doing a really good job of filtering out upstream variations?
Ray
No problem Acko. I can do the tests again on BBB to S03 to DDDAC. Will report back.
Last edited:
I probably wasn't very clear in my earlier post but I used headphones for the experiment for two reasons;
1. since completing my build I have done just about all of my listening on headphones so it was the obvious thing to do from a consistency perspective.
2. I did the experiment at 6am UK time and would have been very unpopular if I hadn't used headphones.
I recognise that listening through headphones isn't the same experience as through speakers and I will repeat the experiment when I bed the new renderer/dac into my main system (OTL tube amp and Lowther back loaded horn speakers), hopefully later today. That said, a good pair of headphones can be very revealing so are quite valid in this type of test.
Ray
Hi Ray, like you I get the best impression of any changes I make, playing through my headphones, of which I have the measured frequency response characteristics .They provide my reference sound. I plug these straight into my DDDAC output without the need to use any op-amp circuit. This direct sound eliminates any coloration of downstream equipment, acoustics etc..
I’m currently also using both a local USB flash drive and a remote NAS mount on my BBB & I personally don’t hear any difference playing the same files from either of the two sources.
I’m currently also using both a local USB flash drive and a remote NAS mount on my BBB & I personally don’t hear any difference playing the same files from either of the two sources.
Pls excuse me here Ray & Guys! I retract my words. One of those moments, it's 40*C here in Perth. 😉
Thank you all for the efforts 
We have come a long way and obviously it has changed the way we look at things 🙂
We have come a long way and obviously it has changed the way we look at things 🙂
I tried the new renderer/dac in my main system yesterday but experienced what I believe is noise from a grounding issue, which rather spoiled things. I haven't experienced an issue with any other sources connected to the amp, nor has noise been an issue with my headphone listening. Some investigation will be required.
I did notice that when I shutdown the BBB (the rest of the renderer/dac remained powered up) the noise disappeared.
Also, I was using the dac's digital volume control so I set the switched attenuator on the amp's input to max, where the switch is open circuit. When I lowered the volume via the switched attenuator, so there was a resistor to ground, there was a step change (downwards) in the noise level.
Anyway work to do. Unfortunately this week is going to be hectic at work so it'll probably have to wait until next weekend...
Ray
I did notice that when I shutdown the BBB (the rest of the renderer/dac remained powered up) the noise disappeared.
Also, I was using the dac's digital volume control so I set the switched attenuator on the amp's input to max, where the switch is open circuit. When I lowered the volume via the switched attenuator, so there was a resistor to ground, there was a step change (downwards) in the noise level.
Anyway work to do. Unfortunately this week is going to be hectic at work so it'll probably have to wait until next weekend...
Ray
OOOh, my boards are just awaiting customs payment so I'll have them maybe later today.
So now I have to decide on which oscillator pair to use as I have both here.
22/24 or 45/49?
I'm going to be bypassing the divider on the S03 and using the setting within the BBB Botic driver so there's no difference in the implementation, but which should I go for?
The 22/24 should have lower phase noise, but the 45/49 are faster.. hmmm......
what would you guys do?
So now I have to decide on which oscillator pair to use as I have both here.
22/24 or 45/49?
I'm going to be bypassing the divider on the S03 and using the setting within the BBB Botic driver so there's no difference in the implementation, but which should I go for?
The 22/24 should have lower phase noise, but the 45/49 are faster.. hmmm......
what would you guys do?
I'd know what to do if it was a car, take the one that makes more noise & goes faster 🙂
🙂
It's all a bit academic at the moment... I had a go last night at mounting the NDK oscillator chips onto the adapter boards (went for 45/49 btw) and quickly found that they're not exactly designed with human beings in mind.... 🙁 I think I got 1 of them mounted ok, but even reading the top of the chip to find the dot for leg 1 is a nightmare, let alone trying to identify which frequency is which. My eyesite's generally pretty good, but even with a magnifying glass I couldn't make it out. Not sure if this is just a particular batch where the printing is very light or if they're all like this?
Is there some other trick to working out which way round they go?
I know what you mean,my eye sight was letting me down as well, a 20x jewelers magnifying glass helps. Or taking a phone picture and blowing that up work to sometimes. Sometimes changing the light angle on the NDK's makes the inscription more readible.
I realised my magnifying glass is only 3x 🙄 It's only a cheap thing I borrowed from my kids 😛 I tried the phone picture, as that normally saves me in such situations, but these are just too teeny
I've just ordered a cheap 40x jeweler's loupe on ebay and I'm going to try solder paste as well to reduce my frustration.
Just I do it.
I can't understand what wrong I do!
It plays at half speed of normal.
a) I set the MCLK/1 but I see that the default amanero set is MCLK/2
b) I removed the R3 (R22) complete from the S03 board and jumper this position. Nothing! The same behavior, plays at half speed.
The 1KHz test is demonstrated as 500Hz test.
Any suggestion?
Acko,
am I right in thinking that the MCK u.FL connection in the S03 digital inputs is sort of performing 2 functions?
So it is the input for MCK which travels through the 4 channel Isolator, gets reclocked by RCK and ends up as an output, but also it's connected to the EXT CLK > Amanero CLK which goes through the 2 channel isolator?
What I'm wondering is because the DDDAC doesn't use the MCK output from the S03, whether it's possible to split the 2 functions at this S03 MCK input so I can still output the EXT CLK signal to my BBB, but also I can input, isolate and reclock an additional data signal? (this way I could have dedicated right left mono signals which the Botic driver can apparently output)
I know it's not possible without cutting and bodging the board a little, but am I understanding it correctly or missing something there?
I won't have the board infront of me for a day or so to trace the tracks and confirm that MCK is connected to both isolators and is therefore input and output at the same time.
thanks,
James
am I right in thinking that the MCK u.FL connection in the S03 digital inputs is sort of performing 2 functions?
So it is the input for MCK which travels through the 4 channel Isolator, gets reclocked by RCK and ends up as an output, but also it's connected to the EXT CLK > Amanero CLK which goes through the 2 channel isolator?
What I'm wondering is because the DDDAC doesn't use the MCK output from the S03, whether it's possible to split the 2 functions at this S03 MCK input so I can still output the EXT CLK signal to my BBB, but also I can input, isolate and reclock an additional data signal? (this way I could have dedicated right left mono signals which the Botic driver can apparently output)
I know it's not possible without cutting and bodging the board a little, but am I understanding it correctly or missing something there?
I won't have the board infront of me for a day or so to trace the tracks and confirm that MCK is connected to both isolators and is therefore input and output at the same time.
thanks,
James