Haha...!We take jokes seriously that is why you are being investigated..
Anyway, while I wait for your SuperCape. I get to play with Turntable setup. That in itself is also debatable with varies parts and combinations.
http://youtu.be/k994pnio0C8
Haha...!
Anyway, while I wait for your SuperCape. I get to play with Turntable setup. That in itself is also debatable with varies parts and combinations.
http://youtu.be/k994pnio0C8
Like!
Thanks Miero, I have see this but did not follow closely as upsampling and the filtering that is obviously required. Still some hope for favorable results from Sync clocking and DxD direct with OSFBypass. My current setup is based on Amanero and was actually preparing to test this but as you have seen there was setback as Amanero failed to take off at 352.8k in Sync mode!
So all eyes on Ray's BBB version but we will need to wait until he manoeuvres into position
In the end it's all down to buffering to counter act variable latency in processing and transmission, any data storage, network or processor does this and this happens at different levels of the OSI model at that. One could even agrue that a local disk is a very big buffer to allow for a very big latency.
If isolation and clocking are equall, an a sufficiently large and fast enough buffer is used, there should be no difference. But this might well be the culpitt that creates the audible difference.
Thanks Linuxfan, possibly this gives the BBB an edge over the EDEL renderer!
Hopefully, the RAMdisk play can be automated with the playlist.
Last edited:
We'll have to agree to disagree on that one
If the player has sufficient processing power and internal bandwidth for what it's doing, (and if we assume a minimum of something like a BBB then it should have, even for high-res), if the player is ground isolated from the dac, and if the player's file buffer is sufficient to cover any latency issues, then I don't see how it's possible to have a difference that can be reliably and consistently identified in a blind test.
I'm happy to be proved wrong, but I just don't see how it can be otherwise. File transfer is very different to other areas of audio.
As for posh network cables, if you go to a business like those trading on the stock exchange, where it's absolutely ruthless and they will do anything they possibly can for tiny increases in speed, bandwidth and reliability to get the edge over the competition, they will be using standard network cabling and ends. Because a data signal that's 100% accurate is technically the same as one that's 100% accurate, beryllium coated, wrapped in silk and rolled on the thighs of virgins
In other news, these have just turned up
I did a lot of searching for a nice solution to mount my S03 (and a google search for 'vibrating balls' can show you many different things...) but in the end these looked like a good option.
Vibration Damping Ball 50gram (8 pcs /bag)
I believe they're for mounting sensitive electronics into model aircraft where vibration is an issue because of the propellors. In theory you need a 5mm hole at each end and you sort of stuff them through. I'll have a go shortly.
An externally hosted image should be here but it was not working when we last tested it.
I did a lot of searching for a nice solution to mount my S03 (and a google search for 'vibrating balls' can show you many different things...) but in the end these looked like a good option.
Vibration Damping Ball 50gram (8 pcs /bag)
I believe they're for mounting sensitive electronics into model aircraft where vibration is an issue because of the propellors. In theory you need a 5mm hole at each end and you sort of stuff them through. I'll have a go shortly.
Ok, so a 5mm drill bit opens the mounting holes out enough, but seems to still leave a bit of metal surrounding. I guess the top and bottom ground planes are joined here?
Seems to work pretty nice!
It's definitely securely enough mounted, but the balls are very squashy, so even with 4 balls the board feels like it's lightly mounted with some good suspension / shock absorption.
Pretty happy with that
Hopefully this will all come together into a nicely cased up bit of kit over the next couple of weeks.
An externally hosted image should be here but it was not working when we last tested it.
An externally hosted image should be here but it was not working when we last tested it.
An externally hosted image should be here but it was not working when we last tested it.
Seems to work pretty nice!
An externally hosted image should be here but it was not working when we last tested it.
It's definitely securely enough mounted, but the balls are very squashy, so even with 4 balls the board feels like it's lightly mounted with some good suspension / shock absorption.
Pretty happy with that
Hopefully this will all come together into a nicely cased up bit of kit over the next couple of weeks.
We'll have to agree to disagree on that one
I have to confess, I'm no sparky! All my feedbacks were based on the ears and certainly no scientific credential. Nevertheless, I take it that you have done these practical experiments and found using a NAS storage has no audible differences against locally served data? Pity..., we are so far part, otherwise it would have been an education/eyes-opener for me!
For those weren't able to recognise the audible differences between cables, whether digital or analogue, pls take it as a blessing...! Well, at least your life saving account is still intact.
Honestly, I haven't made a direct A/B comparison between NAS and local files. I will happily bow to your experience if you can reliable and consistently identify the differences in a blind test, but otherwise I have to work with what I know about computer networking and digital file transfers.I have to confess, I'm no sparky! All my feedbacks were based on the ears and certainly no scientific credential. Nevertheless, I take it that you have done these practical experiments and found using a NAS storage has no audible differences against locally served data? Pity..., we are so far part, otherwise it would have been an education/eyes-opener for me!
For those weren't able to recognise the audible differences between cables, whether digital or analogue, pls take it as a blessing...! Well, at least your life saving account is still intact.
I would love to come and have a session, make some comparisons and enjoy some tunes, but as you say it's not too local
I got the next stage of my kit sorted today. BBB running Miero's Botic driver with Squeezelite installed over the top, into S03 with 100mhz clock running Asynch for now, into the DDDAC.
Now I'm just waiting for the BBB>U.FL, clock adapter boards and DDDAC>U.FL boards to arrive and I can get rid of the nasty jumper cables and swap to Synchronous reclocking
Hopefully the postman's not too much longer.....
James,
Here is not to convince no one rather sharing my realistic experiences with CA over the last 24+ months. Would it be convenience for you to please conduct a quick test with your BBB via Squeezelite through LMS vs BBB's locally serves USB-Flashdrive or usb HDD that powered by a linear power-supply (Doede's one is adequate) for us all?
Yes and agreed, after all, the tunes are all the matter!
Here is not to convince no one rather sharing my realistic experiences with CA over the last 24+ months. Would it be convenience for you to please conduct a quick test with your BBB via Squeezelite through LMS vs BBB's locally serves USB-Flashdrive or usb HDD that powered by a linear power-supply (Doede's one is adequate) for us all?
Yes and agreed, after all, the tunes are all the matter!
Guys, it is important to report on your findings and impressions even if it is apparently perceived so that we look into the matter and see whether snake oil or even erotic matters are in play. Remember how digital music that was supposed to be absolutely perfect based on bit logic theory alone no longer holds true as the dynamics of transport were overlooked or ignored in early implementations. Likewise suspending audio equipment on elastic bands or absorber feet was laughable at one stage but we now know why. So there could be many others ....
Last edited:
I did some research on this... Looks like some NFS (Network File System) on TCP transport mechanism. DLNA similar.
So in both cases data needs to go through hoops and loops across network layers before getting into the audio processing unit. Possibly in typical home network this is not so tortuous.
On the other hand a local drive is closer to metal and data gets clocked out directly to the processing unit.
So performance differences will manifest accordingly in the final outcome.
Last edited:
acko, I like your comments in post 1773 about keeping an open mind. So it's timely to jump in with a response to -
Also, we need to be aware that such SQ reports may be true ONLY for a given setup.
Chanh, in the listening test you reference, what application/hardware/configuration were you using when the files were being accessed from NAS?
SqueezeBox/LMS? LMS running on Beaglebone Black? Or LMS running on NAS?
I repeat that this starkly contradicts other credible reports I have heard. But I keep an open mind, and have stored Chanh's report away in my brain for future reference.
Also, we need to be aware that such SQ reports may be true ONLY for a given setup.
Chanh, in the listening test you reference, what application/hardware/configuration were you using when the files were being accessed from NAS?
SqueezeBox/LMS? LMS running on Beaglebone Black? Or LMS running on NAS?
I deliberately avoided that question when it first appeared in post 1749, but now I think I see that you want a "layman's" explanation of the difference between network streaming and network file systems. If so, here's my layman's explanation:
- network mounts, be they CIFS or NFS, have the type of irregular data flows we discussed earlier ... but they are bit-perfect. So they are latency-prone, but 100% accurate. They are carried over TCP.
- streaming protocols used by internet radio services and internet TV services are typcially carried over UDP, to provide timely, reliable media delivery, at the expense of possible data loss and media quality.
- streaming protocols for good quality audio systems typically try to achieve both; regular, interruption-free data transfer with 100% data accuracy. To this end, SqueezeBox developed their own proprietary streaming protocol, which is still highly regarded today, despite SqueezeBox no longer being in existence.
UPnP, for interest's sake, encompasses most of the non-proprietary streaming protocols.
Which is best for audiophile applications? Excluding the non-error-checked streaming protocols, I don't believe you can say.
It will all come down to how the player buffers the data, and how good the playback software performs its "rendering" function.
I'm probably wrong, but think about the networking versus local disk data supplying a software application like sending a letter by mail. The person that sends the letter chooses a level of service and sends the letter. You don't choose how the letter gets over to the recipient. The route the letter follows and the modes of transportation used are not up to you to choose, the post office applies those according the the level of service you chose. All you are guaranteed is that within the time alloted by the level of service you chose, the letter will reach the recipient in one piece that is in the same state (i.e., not transformed into shredded paper, ashes or turned into pulp) as when the sender sent it. The recipient really doesn't know or care how the letter got to him, all that he will see is the letter handed to him when the post office delivers it. There is no "intermediate" or "fractional" or "incomplete" or "noisy" delivery, the letter is delivered as it was sent or it's considered not delivered (i.e., the post office give the sender the money back!).
I'm not referring to streaming services, but to a computer reading a file from an NFS share versus reading it from a local file system, the streaming will occur from the device reading the file to the dac.
I'm not referring to streaming services, but to a computer reading a file from an NFS share versus reading it from a local file system, the streaming will occur from the device reading the file to the dac.
Last edited:
That's quite the rework you are doing. I'm looking forward to seeing the result.
How did you verify the BBB is using the clock from the S03? I didn't know Miero's driver had an Asynch option. I'm suspisious the BBB might default back to it's internal clock.
Last edited:
Maybe I have my terms mixed up, but I've just swapped my rPi for a bbb. So I'm not using external clock into the BBB, just spitting out using the internal 48k. Then the s03 reclocking using a single 100mhz oscillator.That's quite the rework you are doing. I'm looking forward to seeing the result.
How did you verify the BBB is using the clock from the S03? I didn't know Miero driver had an Asynch option. I'm suspisious the BBB might default back to it's internal clock.
This is only a temporary halfway stage till my boards turn up and I can mount those teeny clock chips and use ufl cables. Then I'll switch to proper synchronous clocking with 2 oscillators and clock select.
I'm planning to bypass the s03 divider chip and input the clock frequencies into Miero's Botic driver as that seems to be the cleanest way.
Hopefully any day now....
You are absolutely right if file transfer is the intention and no one doubts about the 100% accurracy of data. After all most of us downloaded Miero's distribution from another part of the world with confidence. Download times varied but who cares about this. On the other hand a music player will attempt to play as soon as the first few bytes are received so basically renders on the run and this is where timing becomes critical. We are not talking about clicks and pops which are the extreme cases but jitter from minor variations in timing. So to counteract this effect some buffering is usually employed at the receiving end and even re-clocked with a separate ref clock (So terms like ASync USB-I2S)
Buffers are usually small to allow sufficient level to steady the stream but they could also be very deep like Ian's FIFO at the expense of longer startup times.
Of course you can wait for a complete file transfer-copy to a local disk or better still to a RAM drive before play in which case there is nothing to worry about transport layer latencies. So I would think music 'streamed' this way from network or even cloud drive will sound the same as a locally served one. Linuxfan has already indicated how to RAM drive from MPD -BBB. Perhaps Chanh or others can now test this case with their setup
Last edited:
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.