i made quite a discovery today, tho its a quite common advice but i thought its "nonsense/unnessecary" (i probably ever wont asume something because of logic anymore) (since MPD should be buffered and two mpd tasks already have high priority, the two where the dev thinks it necessary)
but i searched for my problem that MPD hangs sometimes while streaming over DLNA, -IF- MPD has its own core and its underclocked
i finally tried increasing the nice priority of the MPD systemd service, this made a -HUGE- difference, i actually cant believe how huge the difference is (the differences between isolated cpu cores and not and underclocked cpu is actually way smaller)
i actually cant believe that the MPD developer says raising priority is nonsense, it sounds like a new, way better, dac now in comparision
and it was enough to make it nice level -1 instead of 0, everyone should try this!!
i dont think this is something generally, like raising priority always helps, but actually a issue in MPD, it NEEDS higher priority, not just on the tasks the developer thinks it does (since two MPD tasks already run with -40 RT priority)
this also solved the problem of MPD getting stuck at 100% cpu, atleast so far tho it happens quite rare so i have to test further
for me this was THE discovery SQ-Wise in MONTHS, im not joking
but i searched for my problem that MPD hangs sometimes while streaming over DLNA, -IF- MPD has its own core and its underclocked
i finally tried increasing the nice priority of the MPD systemd service, this made a -HUGE- difference, i actually cant believe how huge the difference is (the differences between isolated cpu cores and not and underclocked cpu is actually way smaller)
i actually cant believe that the MPD developer says raising priority is nonsense, it sounds like a new, way better, dac now in comparision
and it was enough to make it nice level -1 instead of 0, everyone should try this!!
i dont think this is something generally, like raising priority always helps, but actually a issue in MPD, it NEEDS higher priority, not just on the tasks the developer thinks it does (since two MPD tasks already run with -40 RT priority)
this also solved the problem of MPD getting stuck at 100% cpu, atleast so far tho it happens quite rare so i have to test further
for me this was THE discovery SQ-Wise in MONTHS, im not joking
Not yet, still the normal RPI4 with moode audio
maybe its something moode specific since moode uses a own mpd fork
I have one black, but I use that with a display. I have several greens (cheaper no hdmi) that I use for lots of other stuff. I've been moving to pi's mainly for cost for projects and the much deeper hobby base. But beaglebones have more I/O's, builtin flash for storage and some low end A/D's onboard. I've also found the beaglebones to be tougher. I've had some in outdoor operation for 5+ years no issues. Pi's I've had several go poof on power outages, which the beaglebones came thru ok on. Plus I have had beagles in the past, great dogs. Raspberry pi is just ok. Prefer pecan.
I’m running the black with a custom OS I found in the diy audio forum. The black has a significantly cleaner power section that makes it superior to the pi as a streaming device.
I bought a similar seeed studio board to the one you mentioned ordering. Flashing the emmc took a little googling. If you don’t already have jumper cables, I’d suggest you grab a couple.
with the CM4 flashing the EMMC is somewhat painless from what i read, just plug in a usb c cable from your pc and turn on a switch so the CM4 goes into usb device mode, then you can basicly use it as a usb stick
--
tho you guys got me curious, how different sound different SBC`s ?
im still leaning heavly towards the CM4 because of better hardware/software combatibility and futureproof-ness but atleast im curious how other SBC`s compare
--
Also i will probably start looking into other distro`s then moode audio, what you guys prefer?
tho i kinda dont wanna start from scratch with for example dietpi, this seems too much of a hassle, specially if you need to start all over again at some point for whatever reason
@Ghoostknight - you got the waveshare board right? I bought a different one. I was expecting to be able to do as you suggested and just use the EMMC as a flash drive. Instead I had to short a couple of pins to get it into the right mode. It wasn't hard, just not well documented. My board is from SEEED studio though, so maybe yours operates differently. Again, not hard, just took me awhile to track down the procedure.
As for the Beagle-bone black, the board employs mostly LDO's as opposed to switching regulators and there's a direct path from 5.5mm power input to the USB module on the implying that the USB path is less influenced by the rest of the electrical noise in the device. I haven't done any measurements but of all of the devices I've tested, this one sounds the best. I'm not sure if it's the hardware, the software, or both, but I'm using it as a Roon Endpoint. Here's a screen shot of the way the endpoint can be used and a link to the software developed by DIY Audio member PPY. I don't know enough about Moode to speak to compatibility. I should also mention this software is specific to the Beagle-Bone.
https://puredsd.ru/
As for the Beagle-bone black, the board employs mostly LDO's as opposed to switching regulators and there's a direct path from 5.5mm power input to the USB module on the implying that the USB path is less influenced by the rest of the electrical noise in the device. I haven't done any measurements but of all of the devices I've tested, this one sounds the best. I'm not sure if it's the hardware, the software, or both, but I'm using it as a Roon Endpoint. Here's a screen shot of the way the endpoint can be used and a link to the software developed by DIY Audio member PPY. I don't know enough about Moode to speak to compatibility. I should also mention this software is specific to the Beagle-Bone.
https://puredsd.ru/
Attachments
yes this one: https://www.waveshare.com/wiki/CM4-to-Pi4-Adapter , i already have it here with a CM4 Module, i just didnt got around to try them out yet but most parts for my mods are here too or on its way, i hope to realistically get it done the streamer in around 3-5 months (im kinda slow 😀)
ah, interesting, yea the switching regulators kinda worry me the most on the CM4, i have to look how much additional filter capacitors do here for each voltage rail
but yea it kinda makes sense, the beagleboard looks very minimalistic, just unfortunate that you cant tell if its software or hardware (this seems like a general culprit of comparing SBC`s maybe except DietPi which supports many?)
--
i kinda looking forward to moving away from Moode after looking a bit around, i actually like the stand-alone MPD interfaces way more than the moode one (and would probably use a windows or mobile client too) in this case it also makes sense that the webinterface of GentooPlayer just offers Config options, it was/is probably just more a fear to let go moode since i use it since 2-3 years and havent tried many OS`s yet (just volumio/moode, i wanted to try picoreplayer but wasnt a fan of the whole logitech thing)
Also DietPi looks somewhat good and probably easier to setup than i thought
Dietpi is fantastic and I wish it supported more hardware. I may have to learn how to create custom dietpi installs for different hardware. They have a tutorial for that. For what it’s worth I’ve compared rpi, cm4, neopi nano, le potato and beagle board and have them all here to test things moving forward if anyone has any ideas. Because I stream all of my music I’m not really reliant on MPD so I can’t comment on that specifically.
yup it looks very good tho i wished it had a RT kernel option (to try it out)
did you try a -very- minimalistic setup? in your case it would be enough to have a DLNA receiver which streams to ALSA directly
--
i was reading a bit the last two days and watching for example this one:
And i was wondering... "bitperfect playback"
i dont think tweaking the OS is actually doing anything to the musicdata itself, specially if we can believe what engineers etc say
and if we question data integrity, its probably nonsense since computers/networks wouldnt work then
unless some specific software fcks up maybe for example buffer handling?
but what if its just about actually reducing "electrical noise" from the machine that is connected to the dac (tho there must be more since i also hear differences with galvanic isolation over usb... 🤔 maybe noise actually going back to the AC Lines and "infecting" other close-by devices?)
but this mostly means its best to keep the "musicstreamer/endpoint" as minimalistic as possible (and also tweak the few software components it has) for example MPD and upmpdcli for DLNA
and thinking about the most minimalistic endpoint....
wouldnt be roon`s approach actually be superior to most other alternatives? processing (DSP, uncompressing flac etc) takes all place on the somewhat powerful roon core machine which is "isolated" and preferable a few rooms away while on the endpoint the music data which is streamed over the network is just routed to ALSA and the output device
i dont think it gets more minimalistic than this regarding the endpoint if we can believe that it still receives bitperfect music but not saying the roon endpoint cant be tweaked OS-wise (here is a little read about roon https://help.roonlabs.com/portal/en/kb/articles/sound-quality#Some_Basics_First )
what you guys think is the "real reasons" ,specially regarding os tweaking, that makes a difference? And what is the best approach going forward? While we hear differences tweaking things there must be some "universal solution" or best approach to this
Last edited:
@Ghoostknight I'll check out the video. I think there are lots and lots and lots of variables and why some people have huge aha moments while others don't. Today my setup is ROON on a fanless NUC sending Tidal hi-res (44.1 16bit) to HQPlayer which is upsampling to 705.6 and doing some other filtering before sending that file over the network to my Roon endpoint (beagle bone black with PureDSD OS). That's connected via USB to my DAC. The HQPlayer thing is a new test I'm playing around with and perhaps not super relevant to this discussion.
From what I've read MPD is very susceptible to OS changes. I'm not using MPD as files are being streamed from the internet. I think that's an important starting place because it makes sense that the player is actually having an effect of music, especially if there's any type OS going on in the computer. The biggest thing I've noticed in terms of OS noise changing sound has been in overclocking/underclocking, but in fairness the endpoint isn't doing anything except acting as a conduit between the Roon Core device the DAC.
Now why not just plug the DAC directly into the Roon Core? That's where we get into the second part of your question, and honestly the one that I've been more interested in all along. I do believe that in terms of streaming in a Roon or HQPlayer endpoint scenario... The electrical noise is more interesting than the OS noise. And yes, it's system dependent. I read a lot about devices with Galvanic isolation at the USB input. In my brain I read isolation and I think brick wall. It's either isolated or it isn't. That hasn't so much been my experience. So the better the DAC's USB is galvanically isolated from the streaming device, the less electrical noise gets passed to the DAC and is allowed to enter the analog chain. So where else is noise entering the endpoint? It's own power supply? Easy fix, add a LPS? What else is connected to the endpoint? Ethernet? I've got PoE running all over my house. I wonder if that can pass on electrical noise. Easy fix, break your ethernet run with an optical media converter and power that with another LPS. We're getting deep into the crazy at this point, but I think this is the fun stuff. That's how I got to the Beagle Bone. The power chip in the device is a TPS65217. Google it if you like, but it's a much cleaner power implementation. I actually appreciate that it's powered off a barrel jack too. I get USB is convenient, but it's less fiddelly to have the barrel jack. If you look at all of the fancy streamers, most of them are touting LDO's and galvanic isolation. The only thing I don't have that I wouldn't mind playing around with is i2s, but my solution was less than $100 and I know that my USB signal chain is as clean as it can be. The one downfall I've run into so far is that the Beagle bone has 10/100 ethernet and only one USB2 port. That's it, so you're not going to be streaming DSD1024 if that's your thing. I've maxed out the ethernet port at 705.6. I'm going to message the developer of the PureDSD software to see if it will work with the Beagle Bone AI-64 which is spec'd with more modern features like USB 3 and gigabit ethernet while retaining its preference for linear power. Did I pull the lid off of the can of worms?
.
From what I've read MPD is very susceptible to OS changes. I'm not using MPD as files are being streamed from the internet. I think that's an important starting place because it makes sense that the player is actually having an effect of music, especially if there's any type OS going on in the computer. The biggest thing I've noticed in terms of OS noise changing sound has been in overclocking/underclocking, but in fairness the endpoint isn't doing anything except acting as a conduit between the Roon Core device the DAC.
Now why not just plug the DAC directly into the Roon Core? That's where we get into the second part of your question, and honestly the one that I've been more interested in all along. I do believe that in terms of streaming in a Roon or HQPlayer endpoint scenario... The electrical noise is more interesting than the OS noise. And yes, it's system dependent. I read a lot about devices with Galvanic isolation at the USB input. In my brain I read isolation and I think brick wall. It's either isolated or it isn't. That hasn't so much been my experience. So the better the DAC's USB is galvanically isolated from the streaming device, the less electrical noise gets passed to the DAC and is allowed to enter the analog chain. So where else is noise entering the endpoint? It's own power supply? Easy fix, add a LPS? What else is connected to the endpoint? Ethernet? I've got PoE running all over my house. I wonder if that can pass on electrical noise. Easy fix, break your ethernet run with an optical media converter and power that with another LPS. We're getting deep into the crazy at this point, but I think this is the fun stuff. That's how I got to the Beagle Bone. The power chip in the device is a TPS65217. Google it if you like, but it's a much cleaner power implementation. I actually appreciate that it's powered off a barrel jack too. I get USB is convenient, but it's less fiddelly to have the barrel jack. If you look at all of the fancy streamers, most of them are touting LDO's and galvanic isolation. The only thing I don't have that I wouldn't mind playing around with is i2s, but my solution was less than $100 and I know that my USB signal chain is as clean as it can be. The one downfall I've run into so far is that the Beagle bone has 10/100 ethernet and only one USB2 port. That's it, so you're not going to be streaming DSD1024 if that's your thing. I've maxed out the ethernet port at 705.6. I'm going to message the developer of the PureDSD software to see if it will work with the Beagle Bone AI-64 which is spec'd with more modern features like USB 3 and gigabit ethernet while retaining its preference for linear power. Did I pull the lid off of the can of worms?
.
yes atleast i agree with most things, i also heared the most improvement with underclocking, cpuset/isolcpu makes a difference too but not as much as underclocking
and yea i think your approach is the "universal approach" i meant and what i also have currently in mind
1. power supply noise
2. galvanic isolation for all connected things (usb, ethernet) and tho while i still hear differences even with galvanic isolation atleast this makes objectevily sense and is a approach we can follow even without testing 1000 variables
3. general "radiated" noise of the device in the audio chain
specially in your application with roon i dig the beagebone board approach
did you test your previous setup (maybe with a RPI4 like me? where you run everything on the RPI (player, decoding etc)) in comparision to a roon only endpoint? did you hear improvements here? since im considering roon right now (i really like the interface too, tho the price is a hurdle but i would accept it in exchange for the user-friendlyness)
yes if we can believe that bits stay bits i dont think the roon core machine matters much if we make sure the endpoint is as good as possible regarding the points above and i guess you agree since you stayed with roon, this makes things also much cheaper than a dedicated music streamer which costs thousands with probably a similar effect
so my conclusion would be in regard of dedicated music streamers that yes they matter but roons approach is the much better (and in the end cheaper) topology
@Ghoostknight I don't disagree but I also don't know that we need to limit ourselves to Roon. It made the most sense for me because I'm only streaming Tidal. I'm fairly certain there are other ways to stream music from a server to an endpoint that don't involve Roon if we're merely talking about removing electrical noise from the device serving the content to the DAC. Don't get me wrong. I very much enjoy Roon, I just don't want anyone else reading this to think of it as the end all be all or only option.
I have used lots of different endpoint OS's with the raspberry pi with an LPS in a galvanically isolated environment and they mostly sound similar. VitOS was the easiest one to implement that sounded great with Rpi and also worked as a Roon endpoint. There was one I liked a bit better, but not quite as easy to setup. I think I DM'd you about it.
I have used lots of different endpoint OS's with the raspberry pi with an LPS in a galvanically isolated environment and they mostly sound similar. VitOS was the easiest one to implement that sounded great with Rpi and also worked as a Roon endpoint. There was one I liked a bit better, but not quite as easy to setup. I think I DM'd you about it.
Kinda wanna report a new discovery i made, tho im not actually sure what causes the differences i hear but "stock" fedora + pipewire + easyeffects sound better than my tweaked moode setup with camilladsp
1. fedora + pipewire + easyeffects is actually the best sound i heared from desktop linux so far... (also way better than Windows + EqualizerAPO, which made me switch again to linux)
1.1 pipewire seems way superior to pulseaudio not only in versatility (it can be used as jack and pulseaudio replacement at the same time) but also in soundquality, pulseaudio actually sounded untweaked worse than windows a few years ago
2. easyeffects sound better than camillaDSP for simple tasks (make sure to use "SPM" (or atleast "FFT") mode instead of "IIR" for the easyeffects equalizer plugin), im actually considering migrating to easyeffects since i dont need pure "DSP" functions to build multiway systems
3. im not sure where some of the improvement comes from but i kinda believe MPD on moode is degrading the sound quite a lot, thats why tweaking process priority etc helps in the first place, its bad to start with, atleast this is how it looks/feels to me
4. since the stock fedora + pipewire + easyeffects sound better than my tweaked moode system im actually unsure what to believe now, are we really reducing "noise" to improve performance?
5. this test
shows that there is difference in software packages, so im really wondering if software just isnt perfect always (even if devs like to say that) but tweaking prioritys etc help improve "not so great" software, maybe a better solution for us is actually trying different software
6. really not sure what i should do now going forward with my raspberry pi setup since my desktop actually sounds superior for the first time even if the same(!) system sounded way worse before with different os/software
kinda considering a dietpi + pipewire + easyeffects setup, probably good for trying MPD on its own also
1. fedora + pipewire + easyeffects is actually the best sound i heared from desktop linux so far... (also way better than Windows + EqualizerAPO, which made me switch again to linux)
1.1 pipewire seems way superior to pulseaudio not only in versatility (it can be used as jack and pulseaudio replacement at the same time) but also in soundquality, pulseaudio actually sounded untweaked worse than windows a few years ago
2. easyeffects sound better than camillaDSP for simple tasks (make sure to use "SPM" (or atleast "FFT") mode instead of "IIR" for the easyeffects equalizer plugin), im actually considering migrating to easyeffects since i dont need pure "DSP" functions to build multiway systems
3. im not sure where some of the improvement comes from but i kinda believe MPD on moode is degrading the sound quite a lot, thats why tweaking process priority etc helps in the first place, its bad to start with, atleast this is how it looks/feels to me
4. since the stock fedora + pipewire + easyeffects sound better than my tweaked moode system im actually unsure what to believe now, are we really reducing "noise" to improve performance?
5. this test
6. really not sure what i should do now going forward with my raspberry pi setup since my desktop actually sounds superior for the first time even if the same(!) system sounded way worse before with different os/software
kinda considering a dietpi + pipewire + easyeffects setup, probably good for trying MPD on its own also
Last edited:
Hi there.
Fedora is IMO the best OS out there. I am running it for years. Fedora is ways ahead in terms of up-to-date software compared
to Debian/Raspberry Pi OS or e.g. Ubuntu.
That can make a difference. I even have a small Fedora Desktop installation running on a RPi4 now. (Not recommended for audio though)
However. No OS is better tailored to Raspberry Pi then Raspberry PI OS. To me it's a must.
I still think a well tweaked RPi4 can be a better streamer. That might change if you run heavy duty DSP.
In my case nothing beats my PI. And yes, I am running a rt-kernel and some heavy duty tweaking.
And. I am running @2GHz+. That sounds best to me. If you underclock you might even catch network errors - been there done that - seen that.
Now. You guys need to make sure that you gotta stable power rail on the RPI. A PS with 30inch 5V DC cable won't help.
I have a couple of low ESR OScons (1500uF) and a small Wima attached to the GPIO 5V. On the scope that looks much better..
Earlier somebody mentioned the CM4. I tested them all - hooked up to Waveshare boards.
If you run USB audio devices. Forget it!!!! It's crap. These Waveshare MBOs don't have the PI4 USB3 controller. Therefore they run pretty similar
to what we know from PI3s. You'll have a hard time to get rid of XRUNs.
If you run an audio HAT on a CM4 though - I do, an Allo Katana - It'll do.
However. Maintenance on a CM4 comes with serious challenges for most people.
E.g. RPi eeprom-firmware is still under development and that needs to get updated regularly.
That'll be your first CM4 hurdle. 😉 And there's more. EEProm backups!?!? So. Better stay away.
Let's hope that we'll see some RPi4s back in the stores later this year. Meanwhile these guys almost got a whole industry branch killed.
Not sure how all these 3PP manufacturers and the foundation itself survived this mess.
Enjoy.
Fedora is IMO the best OS out there. I am running it for years. Fedora is ways ahead in terms of up-to-date software compared
to Debian/Raspberry Pi OS or e.g. Ubuntu.
That can make a difference. I even have a small Fedora Desktop installation running on a RPi4 now. (Not recommended for audio though)
However. No OS is better tailored to Raspberry Pi then Raspberry PI OS. To me it's a must.
I still think a well tweaked RPi4 can be a better streamer. That might change if you run heavy duty DSP.
In my case nothing beats my PI. And yes, I am running a rt-kernel and some heavy duty tweaking.
And. I am running @2GHz+. That sounds best to me. If you underclock you might even catch network errors - been there done that - seen that.
Now. You guys need to make sure that you gotta stable power rail on the RPI. A PS with 30inch 5V DC cable won't help.
I have a couple of low ESR OScons (1500uF) and a small Wima attached to the GPIO 5V. On the scope that looks much better..
Earlier somebody mentioned the CM4. I tested them all - hooked up to Waveshare boards.
If you run USB audio devices. Forget it!!!! It's crap. These Waveshare MBOs don't have the PI4 USB3 controller. Therefore they run pretty similar
to what we know from PI3s. You'll have a hard time to get rid of XRUNs.
If you run an audio HAT on a CM4 though - I do, an Allo Katana - It'll do.
However. Maintenance on a CM4 comes with serious challenges for most people.
E.g. RPi eeprom-firmware is still under development and that needs to get updated regularly.
That'll be your first CM4 hurdle. 😉 And there's more. EEProm backups!?!? So. Better stay away.
Let's hope that we'll see some RPi4s back in the stores later this year. Meanwhile these guys almost got a whole industry branch killed.
Not sure how all these 3PP manufacturers and the foundation itself survived this mess.
Enjoy.
I keep sKit alive. That's about it. (I am not using pCP myself.)
sKit was a another project to show and prove that OS optimizations
can make an audible difference.
I was considering to do something (much better) for the Raspberry PI OS myself.
I am a bit worried about the (continuous) effort though.
sKit was a another project to show and prove that OS optimizations
can make an audible difference.
I was considering to do something (much better) for the Raspberry PI OS myself.
I am a bit worried about the (continuous) effort though.