Dummies Guide to Pi2AES! Throw away your PC or laptop.

Disagree.

A USB-first DAC like Mobius is best using a USB connection, not a clean external source.

A relocking DAC like a Gungnir, Yggdrasil, or Holo May will PLL/reclock, eliminating jitter and making all decent digital sources equal.

The benefits of a good digital source are greatest for DACs that don't fall into either of these camps, like a Bifrost.

 

The unison dacs weren’t designed as usb first, they were designed with usb that didn’t suck.

And a clean source might help more in cases where the dac isn’t doing a very good job but it will help all dacs regardless.

 

Agreed!! And I don’t believe in modius or any other dacs being “USB first” dac as if schiit or other companies would actually use interior AES or coax in their lower model dacs and superior for higher models in their lineup.

Most importantly, ALL DACs will thank you and benefit from feeding it with clean source!!!

Deric

 

Anyone that uses MPD...found something interesting today that might help. MPD is the Music Player Daemon, which is what most Pi Distros use including moOde, Volumio, and likely a host of others.

If you are like me and fumble finger your phone and load your entire music library to the playlist instead of just browsing, it will likely lock up your Pi. The website to control will become quite unresponsive. I did this once and got so frustrated and re-flashed the micro-SD card. However, there is an easier option.

In case this happens, just SSH into the Pi. Run command

Code:

mpc clear

It should not require elevated permissions, but if it does you can always run with sudo.

Anyway, that command clears the MPD playlist and everything should go back to normal.

PS - there are tons of documentation on MPD and MPC (the controller for MPD), but I found this one the easiest for some quick commands - https://linux.die.net/man/1/mpc

 

You can also use any one of the many mpd clients from the comfort of your phone/laptop. I like MPDroid on phone and ncmpcpp on desktop. Better than the web interfaces.

 

Thanks Garns! Just to save time for others...

ncmpcpp installation instructions are here

mpdroid for Android is here

 

When I still had time to contribute to moode one of the things I did was optimize it to work better with large lists because browsers hate them. There’s an internal 10k item queue limit (idk if moode or mpd) but I used to load my entire library (the first 10k tracks anyway) as an easy way to test things and it got to the point where while not exactly pleasant it didn’t lock things up anymore and you should only pay the rendering cost once. And since the slow part doesn’t happen until you switch to the playback screen and show the list you can always clear the queue by selecting a smaller item (like a single album) and selecting clear/play.

 

First off, thanks for your good work sir!
I could never get to this point. Chrome would always time out and say site is not working and either stop or wait. I clicked Wait like 5 times and could never get rhe UI to load up. (I do have a 2b, and not a Pi 3 or 4). So going through the SSH gives another option that I wish I knew rhe first time I made that mistake and didn't load up my card.

Also, since I mentioned, moOde 7.0 now has the ability to backup your MPD library, settings, and radio stations, so if you do have to re-flash, you can just load the backup and everything gets back to where you had it.

 

Please explain.. I guess you have to disagree with one or more of the following.

* What is transmitted over AES/SPDIF is a digital bitstream + timing information.
* Even entry-level streamers and cables will transmit the bitstream data without errors.
* The quality of the timing information will depend on the clock, transmitter, cable etc - with lower quality known as jitter.
* Inexpensive DACs will use the input timing data to generate audio, so their output will reflect the level of jitter ( I used Bifrost as the example)
* Better DACs will reclock / PLL and eliminate all source jitter (I used Gungnir/Yggdrasil/Holo May as examples)

 

Agreed with all but the last. Unless you can measure the jitter at the output of the PLL, this feels like too broad a statement. As a design engineer who has designed PLL's in the distant past, they are subject to variations due to their own crystal jitter, power supply noise, temperature drift, etc. The quality of the design and it's components matters. In any case, nothing eliminates all jitter!

 

Thanks Michael

I didn't mean to suggest that the output of the PLL would have no jitter.. rather that it wouldn't retain any of the jitter from the digital source. Different jitter, sure!

 

Actually I realize the second from last is also an issue for me. All SPDIF/AES receivers have a PLL to recover the clock. AES/SPDIF bitstream encodes the clock into the data stream and must be "recovered" by the receiver using a PLL. This is from one of the best receivers out there, the CS8416:



The jitter output of the CS8416 is still ~200psec rms. Look at the plots @GoldenOne has on his web site to get an idea of where 200ps ranks.

https://goldensound.audio/2021/07/22/pi2aes-streamer-measurements-and-5v-psu-mod-instructions/

 

Thanks Michael, this is great. I have seen PLL used to imply reclocking, but what you're saying suggests PLL doesn't imply reclocking at all.

 

You might have seen reference to what is called ASRC or "Asynchronous Sample Rate Converter" This uses a buffer to hold the input data using the received clock, but then clocking it out using a local, hopefully lower noise clock. They will decouple input jitter (as long as it not too bad) from the output.

BTW, there are DAC's with PLL's that also include additional circuitry to reduce the final jitter. In that area I have no experience, just PLL's and ASRC's.

 

An old and painful subject...

Still having problems with loss of wi-fi. I think it has to do with 5Ghz band. One of my Pis is the 3b version - it only supports 2.4GHz and *never* disappears from the network. The other is a 3b+ and supports and connects on the 5G band and disappears regularly. They both have exactly the same config settings and both run Volumio. The connection band is the only difference I know of between the two.

I've tried everything that I've found on the webs to force the 3b+ model to only connect using 2.4GHz but it's not working.

Any thoughts? Can I somehow force the 2.4 band for that device via the router?

 

Id depends on the router. On mine, a UniFi Dream Machine, I can create a separate 2.4GHz-only WiFi network that I then use for those 2.4GHz devices.

 

Give your 2.4Ghz wireless and 5Ghz wireless different SSIDs. It might prevent roaming and band selection for devices that can do that. But in my experience, most devices just grab onto one wireless band until grim death anyway.

Alternatively, if your router can create a guest network only on the 2.4Ghz band (leaving your existing 2.4/5 networks the same), then connect the Pi2AES to that guest network. For example, I have all my Amazon devices all on their own 2.4Ghz guest network.

 

Now when Pi2AES production has stopped, what is the future? Besides Mercury, which will be expensive, not so flexible and definitely not for everyone in any case - where are we going with audiophile quality Raspberry Pi? Back to HiFiBerry Digi2 Pro?

 

Who said production has stopped?

 

"Permanent and final. There are only 18 units left for pre-order in what will likely be the last batch we build. Several parts have become unavailable at this time. And according to the manufacturers, no relief until mid 2022.

The PI2AES will be replaced by Mercury (see the coming soon section of the web site) within the next month or so.
Michael Kelly 6 days ago "
at their page. And back to my original question #1719.