tag:blogger.com,1999:blog-4016647060023626891.post4274513543413179275..comments2024-03-01T16:40:26.533+08:00Comments on Am I Experienced?: Respberry Pi with Shairport and USB AudioYtsejamhttp://www.blogger.com/profile/05666140967907135629noreply@blogger.comBlogger12125tag:blogger.com,1999:blog-4016647060023626891.post-84449838420167237132013-05-13T16:37:06.065+08:002013-05-13T16:37:06.065+08:00Yes, but the setup is a little bit different. All ...Yes, but the setup is a little bit different. All my music/video files are stored in iTunes via an iSCSI partition on the NAS. So it is not direct streaming from NAS to AAE/RPi, instead, iTunes "reads" the file from NAS via iSCSI, and streams the music from my Mac to AAE/RPi.Ytsejamhttps://www.blogger.com/profile/05666140967907135629noreply@blogger.comtag:blogger.com,1999:blog-4016647060023626891.post-78055180467067703312013-04-24T15:53:24.745+08:002013-04-24T15:53:24.745+08:00Ytsejam兄請教一個問題
你已以NAS來傳送音樂檔嗎Ytsejam兄請教一個問題<br />你已以NAS來傳送音樂檔嗎小蘇noreply@blogger.comtag:blogger.com,1999:blog-4016647060023626891.post-48257559945095888822013-01-09T00:14:32.900+08:002013-01-09T00:14:32.900+08:00Hi Ytsejam,
What I meant to ask was whether you ...Hi Ytsejam, <br /><br />What I meant to ask was whether you had plans to modify the power supply circuitry "on" the RPi board - the ones that further regulates the 5V input. I'll probably use a simple LT1086 as the 5V external supply for the time being. As for the connector, well, I simply try to avoid them whenever I can. <br /><br />Good to know that the fix is enabled by default.<br /><br />Just a wild guess, perhaps the Async USB implementation of the DDC 192 is better than the DAC? Speaking of oscilloscope measurements, I've been mightily impressed with that of my Gainclone. And I'm not even done rebuilding it! It sounds very impressive when done right.Anonymoushttps://www.blogger.com/profile/14333587695820613460noreply@blogger.comtag:blogger.com,1999:blog-4016647060023626891.post-74415154349907569152013-01-08T05:58:41.267+08:002013-01-08T05:58:41.267+08:00Hello Alex,
For RPi power, I use the "UCC re...Hello Alex,<br /><br />For RPi power, I use the "UCC regulator module" at 5V to power it. The reason for using the UCC is: I have it idle there for awhile, and it just fits the power requirement for my RPi experiment. I believe that a decent 7805 or LM317 based LDO will do a great job here. I think you don't need to remove the miniUSB connector, you can modify and type A USB socket, and solder it on to your LDO output.<br /><br />FIQ is a potential fix for the USB excessive interrupts for RPi. The FIQ code was added to the USB host driver with a knob, so that you can enable/disable it by configuration. As I know, it is now enabled by default in the "Raspbian".<br /><br />Regarding SPD/IF, interestingly, the best result I have today is not the RPi to Async USB DAC.<br />Instead, My RPi goes to DDC 192, which converts USB data to SPD/IF (actually AES/EBU), and then to my DAC. Why? Theoretically, it shouldn't be the best, however, it is. I traced all the digital signal path on my system by oscilloscope before the signal entering the DAC chip. I found that's the best combination. And the listening result verified my electrical observation. Except for this, there are quite a few good reasons to keep the SPDIF, <br /> but let's leave the topic for the next chat.<br />Ytsejamhttps://www.blogger.com/profile/05666140967907135629noreply@blogger.comtag:blogger.com,1999:blog-4016647060023626891.post-36202021399332746492013-01-08T05:02:16.633+08:002013-01-08T05:02:16.633+08:00Hi Ytsejam,
You see, I always "kind of"...Hi Ytsejam,<br /><br />You see, I always "kind of" knew what was going on in the digital audio chain, but you described the processes in a very cohesive and easy-to-understand manner. I wish I had professors bothered to do that back in college! <br /><br />You are right, I made a mistake by oversimplifying the role of Async USB. It is not technically a "reclocking" device, though it does receive data and use its own clock for output. Thank you for the clarification, now I'm certain that the Async USB "IS" the master clock, which makes it even better!<br /><br />I fully agree that an RPi is a natural match for Async USB. The complexity of the PC transport is what eventually drove me away from it. I will not make the same mistake twice.<br /><br />Speaking of power supplies, have you considered modifying the actual RPi board? I'm certain that I will remove the micro USB connector and hardwire a quality linear supply to it, but despite reading the data sheets of the onboard LDOs, beyond that I don't have much of a clue. Any insight you'd like to share? :)<br /><br />My RPi should arrive soon, but I'll probably take a slightly difference approach. I would've gone Airplay - especially with your instructions available - except that it doesn't support high res playback in its current state. That would mean a significant amount of my HD-file collection would go to waste, and like most with Taiwanese parents, I was taught that one shouldn't let good stuff go to waste ;)<br /><br />Instead, Squeezelite would be installed on the RPi, turning it into the "ultimate squeezebox". It will replace the venerable SBT in my system. Absent the main sources of noise that plagues the original Squeezebox - namely display, wifi, and less than ideal onboard supply - the RPi is bound have superior sonic potential.<br /><br />The only thing that concerns me now is the USB/Ethernet issue. As stated, a good portion of my collection is 24/88 or higher, thus "popping" might be much worse in my application. I do remember that you mentioned an "FIQ" fix on Cynical Audio, can you please elaborate?<br /><br />Just a thought, have you considered eliminating SPDIF altogether?Anonymoushttps://www.blogger.com/profile/14333587695820613460noreply@blogger.comtag:blogger.com,1999:blog-4016647060023626891.post-40474097408822330062013-01-06T12:34:37.271+08:002013-01-06T12:34:37.271+08:00(Part two)
Swapping CDs is annoying (at least to ...(Part two)<br /><br />Swapping CDs is annoying (at least to me), so people replaces the CD player with a PC or Mac, <br />from:<br /><br />CD Player --(S/PDIF, data+clock)--> DAC <br /><br />to: <br /><br />PC --(S/PDIF, data+clock)--> DAC<br /><br />Unfortunately, a PC is usually far more complex than a CD player, and it often lacks of a decent power supply.<br />This implies more noise in the "data source" of digital system, and more factors may affects the jitter.<br />And note that master clock is still generated at the PC side.<br />Nobody knows how accurate the clock is on a PC (I'm not talking about the clock for the CPU or GPU, we need the accurate clock for the audio signal), if you have a decent sound card, it might not be a concern.<br />But the problem is, on a PC, there are usually too many noise source. It's hard to deal with noise.<br />I think this is the reason that I don't like the PC to DAC solution, there are too many variables.<br /><br />With AAE solution, I got the benefit from AirTunes. The audio data is sent from the Mac/PC to AAE, and the AAE "plays" the audio in S/PDIF or I2S format, and then sends to the DAC.<br />Please note the definition of "playing", when I say "play", it means the audio data is encoded/incorporated with the clock.<br />For AirTune, the PC/Mac only sends the audio data to AAE, it didn't send the clock.<br />So the audio is actually being "played" on the AAE itself. Like this:<br /><br />PC --(AirTunes, data)--> AAE --(S/PDIF, data+clock)--> DAC<br /><br />For the AAE, the clock for I2S or S/PDIF is generated on the AAE itself. I can minimize the jitter or suppress the noise as possible, it hard to improve the clock of AAE.<br />The first reason is, the clock on the AAE is running at 25MHz, which is for the processor of AAE, not for the audio.<br />And the audio clock is synthesized by the AAE processor. <br />Even I can replace the AAE's clock chip with a better one, I can't guarantee the audio clock is accurate enough.<br />And this is the limitation of AAE.<br /><br />Let's move on to the Async USB. Put it simple, Async USB is just a "clock independent" protocol between your PC and the USB DAC.<br />The audio data (note data only, no clock) is sent to the Async USB, and the audio data is being "played" on the USB device by a dedicate chip, such as XMOS processor, and then encoded/incorporated with the local master clock on the USB device depends on the audio sampling rate.<br />If we built the Async USB into the DAC, it implies that the audio is being "played" and converted within the same device - DAC.<br /><br />The architecture becomes:<br />PC --(Async USB, data) --> Async USB device --(I2S, data+clock)--> DAC<br /><br />Since the master clock is no longer generated by the PC in the Async USB architecture, jitter might not be a concern anymore.<br />But since the Async USB device is powered by the PC, noise will pass through. If we replace the PC with a low noise, simpler architecture device, such a RPi, we actually minimize the noise.<br />The only we need to do is to build a decent power supply for RPi to power up the RPi and Async USB device and minimize the noise.<br />Isn't that simpler then using a PC? :)<br /><br />If we use the RPi with AirTunes, the architecture becomes:<br />PC --(AirTunes, data)--> RPi --(Async USB, data) --> Async USB device --(I2S, data+clock)--> DAC<br /><br />When I firstly power the RPi with a linear power supply, and connect it to the USB Async DAC, I was shocked.<br />Although RPi still has the USB driver issues, small pops and clicks may happend, but the sound quality is much better than my current fine tuned AAE transportation.<br />Hope that BroadCom can get it resolved as soon as possible.Ytsejamhttps://www.blogger.com/profile/05666140967907135629noreply@blogger.comtag:blogger.com,1999:blog-4016647060023626891.post-63710995259216700432013-01-06T12:34:04.446+08:002013-01-06T12:34:04.446+08:00Hi Alex,
To further clarify, IMHO, the magic of A...Hi Alex,<br /><br />To further clarify, IMHO, the magic of Async USB is not casted by the Async USB itself.<br />Let's have a look at the history of digital audio.<br /><br />For digital audio system, since the analog audio signals are "sampled" at a specific frequency, i.e. clock.<br />The device which generates the master clock determined the baseline for jitter.<br /><br />Take a look at CD player, the laser head reads the data from CD, and injects the master clock, then transfers the data via I2S to the built-in DAC chip, and converts the digital signal to analog, and then sends to the external amplifier. However, in those year, the built-in DAC might not be good enough, hence the DAC chip performance becomes a major factor of audio quality. That's why people were crazy about TDA1541 for a while, even today.<br /><br />Due to improvement on DAC chip, people wants a well designed, dedicate device to handle the digital to analog conversion. Because of this, we need a protocol to transfer the data and clock from the CD player to the DAC, that's why you see the S/PDIF or ASE/EBU interfaces.<br />However, on the S/PDIF, since master clock (generated on the CD player) and data are encoded into a single steam, on the DAC side, we need to separate the data and use the PLL circuit to recover the master clock, then convert them into I2S, and send to the DAC chip.<br />The problem is, the master clock is still determined by CD player, even we can recover the master clock perfectly, the quality of the master clock on the CD player set the limits already.<br />That's why some people tried to use a better clock for CD player, or introduce some re-clock circuits on the DAC side.<br /><br />However, people found that since we converted the original I2S to S/PDIF and then recover it back, the impedance of the cable, a small capacitor on the signal path will introduce some difference for the clock, that's we called jitter.<br />If the S/PDIF interface is not well designed between the CD player and the DAC, more jitter will be introduced.<br />That's why some people tried to feed to I2S from CD player directly in to a DAC for bypassing the master clock recovery.<br />(In this case, I usually connects the CDP and DAC via both I2S and S/PDIF, and fine tuned the S/PDIF until I couldn't find the difference in between, then I don't need the I2S connection anymore)<br /><br />Despite of the jitter, if we connects the CD player and DAC by cooper wire, noise will also traverse from one device to another, that introduces another factor - noise.<br /><br />(Part one)Ytsejamhttps://www.blogger.com/profile/05666140967907135629noreply@blogger.comtag:blogger.com,1999:blog-4016647060023626891.post-61180878924407002032013-01-04T12:19:26.176+08:002013-01-04T12:19:26.176+08:00Hi Ytsejam,
(Sorry, just realized I got your id w...Hi Ytsejam,<br /><br />(Sorry, just realized I got your id wrong in my last comment, how rude of me!)<br /><br />Thank you for taking the time to write such a detailed explanation, really appreciate it. I may have to steal that and put it in my new "Dummie's Guide to Hi-End File Audio" e-book for profitzz! j/k ;)<br /><br />Ahem.<br /><br />In all seriousness, your reasoning is sound. And from what I just learned, the Async USB is, in essence, a very cost effective reclocker for file-based audio systems. In my limited experience, a good reclocker significantly reduces the variance between transports, similar to how Async USB minimizes the impact of the host.<br /><br />I'm quite curious how a financially accessible setup like the Pi+"reclocker" (and a great dac ofc) stacks up against commercial offerings that DO cost an arm and leg, such as the legendary Linn Klimax DS.<br /><br />Either way, I find the reclocking Pi to be a very elegant solution, especially when compared to the ancient PC/sound card monstrosity popularized by the good folks over MyAV.<br /><br />I have to admit that I fell victim to the "way of PC" myself, no thanks to fellow inmates on Audio Asylum (the name "asylum" should've been warning enough, but I joined the crazy parade anyway). While tweaking can be fun to an extent, having near-infinite variables and being susceptible to all kinds of crap, are not.<br /><br />To put it in audiophool jargon, the old school PC transport is very jitter-prone, making it a rather poor base to build on. Sure, it's possible to erect a skyscraper on sand, but unless you're an Arab prince (or an M.D. with nothing better to do), why throw away time and money for no good reason?<br /><br />Speaking of which, there's a little drama happening over at myav as I type. Seems like people are fighting over some "NOS" HD5450 graphic card. I don't know if it's sad, hilarious, or both!<br /><br />Sorry about the babbling, I do remember having something constructive to say... Oh right! Thanks to your inspiration, I plan on ordering an Async USB device myself over the weekend. Still torn between several options, but I'm adamant in going Async USB. You'll be the first to know once the new toy arrives! :)<br /><br />On a side note, after consulting with several asylum inmates, it seems that most have migrated to low-power pc+Async USB. Of those who did, ALL agreed that Async USB is both sonically superior and more hassle-free. Looks like we're not alone!Anonymoushttps://www.blogger.com/profile/14333587695820613460noreply@blogger.comtag:blogger.com,1999:blog-4016647060023626891.post-17521584716636925912013-01-02T23:08:35.372+08:002013-01-02T23:08:35.372+08:00Hello Alex,
I don't have experience regardin...Hello Alex, <br /><br />I don't have experience regarding the CM6631 nor TE8022, the only thing I have is the XMOS based DDC 192. But I can share my tiny 2 cents on the Async USB.<br /><br />For other transfer types: such synchronous, adaptive, they rely on the data rate on the USB bus. And the host (your PC/Mac) controls how fast the audio data is transferred on the USB. Hence, the clock of USB "host" plays a critical role. For Async type, the USB host is responsible for transferring data to the USB device at a "free running" frequency. In other words, the audio sampling rate can be independent from USB bus clock. On USB device, received audio data is then be sent to DAC using its own clock. As long as the clock on the USB device is accurate enough, it is much more easier to minimize the jitter. We can take it as: the PCM audio data is being transferred to the USB device, and replayed by it with its own clock.<br /><br />What's the most prominent factor for the sound? IMHO, in the digital world, two terms: jitter and noise. Noise is something very tricky, if you didn't well control the noise, it will pass through the whole audio system. Especially when you are using cooper based media for connections between audio devices. For jitter, a lot of things may contribute to it, including the impedance of the circuit trace on the PCB. Unfortunately, we lived in a world with a lot of jitter and noise. To perfectly "replay" the audio, we'll need to pay a lot of attention on these two factors. <br /><br />So, why using RPi as the USB host? First, it is simple, it has only a few chips on it, to me, it is equivalent to less noise. Secondly, I can install "Shairport" on it for supporting AirTunes, so that I don't have to rebuild my music repository. Put it this way, the only reason for me to use RPi is to minimize the noise. For the jitter, since the audio data is actually "replayed" on the Async USB device, we can leave it to the USB device. <br /><br />In other words, with Async USB, the USB host is no longer important, the only thing you need to pay attention to is the noise, and maybe the functionalities (for ex. AirTunes).<br /><br />I did tried connecting my MBP to DDC 192, and compare it to my modified I2S AAE. Not bad, but it didn't convinced me to replace the current AAE with the Mac + Async USB solution. And i don't want to spend a lot of efforts on modifying the power supply for my Mac, since noise may be sourced from the USB host itself. in this case, no matter how good is the power supply, it just won't help.<br /><br />For RPi + Async USB, with the switching power supply, I realized the potential, since there's no much difference between it and my existing modified, carefully tuned AAE solution. After I replace the switching <br />power of the RPi by a linear power supply, I was attracted, more detail, more harmonics and low-ends. Based on the observation, it implies that AAE has its own limitation (at least the digital), despite that I always want to get rid of its WiFi since that's a potential source of noise to me.<br /><br />For RPi replacement, the ideal solution to me is a simple host with separate LAN PHY and USB PHY. However, most of the hardware solutions today usually have excessive peripherals since people want do everything on it. Put it another way, I just want a simple knife, unfortunately most of the vendors are making swiss knifes in the market. <br /><br />I hope this helps.<br /> Ytsejamhttps://www.blogger.com/profile/05666140967907135629noreply@blogger.comtag:blogger.com,1999:blog-4016647060023626891.post-88300476211192427302013-01-02T20:38:40.951+08:002013-01-02T20:38:40.951+08:00Hi Ytsejam,
Thank you so much for sharing! Your w...Hi Ytsejam,<br /><br />Thank you so much for sharing! Your write-up is a true blessing to the non-tech-savvy audiophools (ie me), allowing us to have a bite of the Pi despite our lack of technical skills.<br /><br />Though the software side of the puzzle has been solved, the hardware aspects of things aren't quite so clear ... to some of us anyway :P<br /><br />I have no practical experience with asynchronous usb devices, so a lot of what you've discussed in the blog(s) seem foreign to me. Would you be so kind as to shed light on their mysterious ways?<br /><br />First off, what are the differences between async usb solutions? I heard that there are other chips capable of handling async usb, such as the CM6631 and TE8802. I'm particularly interested in the CM6631, as I remember reading somewhere that it can draw power from a discrete supply by design! <br /><br />Secondly, what are the most prominent factors affecting sound? Do the "hosts" that async usb devices attach to have a major impact on sound? Have you tried using the DDC 192 with your Mac? How does it compare to Pi?<br /><br />Thirdly, what are your views on commercial "Pi replacements"? With the release of EDO (enhanced digital output mod), the Squeezebox Touch is now capable of handling 24/192 async usb. It's obviously more pricey, but everything is handed to you on a silver platter, while being perfectly moddable. While it may or may not sound as good as the Pi, I'm pretty sure that its network doesn't screw with the usb ;)<br /><br />Thanks again for bearing with my newbie questions. Happy New Year, listen long and proper!Anonymoushttps://www.blogger.com/profile/14333587695820613460noreply@blogger.comtag:blogger.com,1999:blog-4016647060023626891.post-62440455207130462382013-01-02T15:56:27.738+08:002013-01-02T15:56:27.738+08:00我是以 Mac OS X 為例,介紹如何 SD Card 給 RPi 用。若您的 OS 是 wind...我是以 Mac OS X 為例,介紹如何 SD Card 給 RPi 用。若您的 OS 是 windows ,RPi 官方網站上有提供程式可以使用。Ytsejamhttps://www.blogger.com/profile/05666140967907135629noreply@blogger.comtag:blogger.com,1999:blog-4016647060023626891.post-27022487248460536892013-01-02T15:47:06.623+08:002013-01-02T15:47:06.623+08:00所以說 Ytsejam兄是以Mac to Respberry Pi to USB?
若不先以Mac格...所以說 Ytsejam兄是以Mac to Respberry Pi to USB?<br />若不先以Mac格式化SD會如何呢?小蘇noreply@blogger.com