Hi blueray,
It's lightMPD that is using polipo.
If you used symphonic-mpd v0.6.x at the same time as lightMPD, then you can use It's a year and a half ago, so you can't blame me for confusing it.
There is a derivative version called smpdplayer which uses the modules of symphonic-mpd.
That one could be configured to combine with lightMPD (upnpgw).
Perhaps you used smpdplayer?
It's lightMPD that is using polipo.
If you used symphonic-mpd v0.6.x at the same time as lightMPD, then you can use It's a year and a half ago, so you can't blame me for confusing it.
There is a derivative version called smpdplayer which uses the modules of symphonic-mpd.
That one could be configured to combine with lightMPD (upnpgw).
Perhaps you used smpdplayer?
Hi blueray,
Oh, really?
I'm very sorry.
I have never used polipo in symphonic-mpd. However, I have evaluated its effectiveness.
Maybe some of the files used in the evaluation tests got mixed up in the SD image.
Please forgive me for my misunderstanding.
@papalius
Forget phofman. I'm having the same discussions with that guy since 2008.
He's one of the worst - didn't learn anything in more than a decade.
phofman has never shown any positive contribution in that area that I am aware of.
These type of guys are simply not willing or not able to change their mindset.
And the funny part. These guys never ever provide anything to support their own claims - proving that you are wrong !!!
... and then keep demanding to provide prove on your side.
If you do so they simply ignore it. And keep spreading their BS all over the place.
I also had similar discussions over at squeezebox forum about my Touch Toolbox
around 2011. With that Toolbox I was simply introducing Linux OS optimizations.
The Squeezebox Touch was running a rt-kernel by default already then btw!!
All these "snakeoil screamers" asking for ABX-double-blind-crap suddenly
became quite when a recording was done with Audio Diff maker.
Doing an AB test, by recording and comparing a complete music track and not just a
stupid test signal - it was done with and without Toolbox.
No. The result wasn't "no change". Nope. Surprise, surprise, the measurement had shown a clear change on the audio signal.
The Touch Toolbox was my first try to show in public that OS optimizations can change
the situation. My intention was to let the people decide. Just try it.
Thousands of people used that Toolbox happily.
It didn't take long and the snakeoil-screamers were back.
OK. I thought. I didn't expect anything else. I considered it an ideological issue
from that point on. These guys simply love that destructive and divisive attitude instead of being constructive. Usually these folks are quite narrow minded.
Anyhow. Next time I provided Moode with some optimizations. Including the rt-kernel.
Just to let the people judge and decide once more. And guess what. There are still people running Moode with that long outdated 3.8.x or whatever version it was a couple of years back, because they think that rt-version still performs best in their system.
However. One thing I learned over all these years. The better the HW (DAC/power supply/motherboard/etc.) the less impact you'll see from OS optimizations/changes.
It'll always be the question how the DAC can fight all kind of noise, EMI/RFI, (data-)jitter, power fluctuations,... These physical nasties caused by or routed through the transport are IMO the actual sources that impact the DAC performance.
SW changes/optimizations/flaws simply impact exactly these nasties.
With a perfect DAC we wouldn't have these discussions. Because the bits are not changing their logical values.
Unfortunately I havn't found the DAC that can ignore the physical environment surrounding these logical bits yet.
Finally. It's good to see that you guys try to take it even further. Keep going! Many
people are appreciating these efforts.
Enjoy.
Forget phofman. I'm having the same discussions with that guy since 2008.
He's one of the worst - didn't learn anything in more than a decade.
phofman has never shown any positive contribution in that area that I am aware of.
These type of guys are simply not willing or not able to change their mindset.
And the funny part. These guys never ever provide anything to support their own claims - proving that you are wrong !!!
... and then keep demanding to provide prove on your side.
If you do so they simply ignore it. And keep spreading their BS all over the place.
I also had similar discussions over at squeezebox forum about my Touch Toolbox
around 2011. With that Toolbox I was simply introducing Linux OS optimizations.
The Squeezebox Touch was running a rt-kernel by default already then btw!!
All these "snakeoil screamers" asking for ABX-double-blind-crap suddenly
became quite when a recording was done with Audio Diff maker.
Doing an AB test, by recording and comparing a complete music track and not just a
stupid test signal - it was done with and without Toolbox.
No. The result wasn't "no change". Nope. Surprise, surprise, the measurement had shown a clear change on the audio signal.
The Touch Toolbox was my first try to show in public that OS optimizations can change
the situation. My intention was to let the people decide. Just try it.
Thousands of people used that Toolbox happily.
It didn't take long and the snakeoil-screamers were back.
OK. I thought. I didn't expect anything else. I considered it an ideological issue
from that point on. These guys simply love that destructive and divisive attitude instead of being constructive. Usually these folks are quite narrow minded.
Anyhow. Next time I provided Moode with some optimizations. Including the rt-kernel.
Just to let the people judge and decide once more. And guess what. There are still people running Moode with that long outdated 3.8.x or whatever version it was a couple of years back, because they think that rt-version still performs best in their system.
However. One thing I learned over all these years. The better the HW (DAC/power supply/motherboard/etc.) the less impact you'll see from OS optimizations/changes.
It'll always be the question how the DAC can fight all kind of noise, EMI/RFI, (data-)jitter, power fluctuations,... These physical nasties caused by or routed through the transport are IMO the actual sources that impact the DAC performance.
SW changes/optimizations/flaws simply impact exactly these nasties.
With a perfect DAC we wouldn't have these discussions. Because the bits are not changing their logical values.
Unfortunately I havn't found the DAC that can ignore the physical environment surrounding these logical bits yet.
Finally. It's good to see that you guys try to take it even further. Keep going! Many
people are appreciating these efforts.
Enjoy.
Ignoring phofman is a not a very bright idea. He is one of the (unfortunately few) people here with enough real knowledge to question all the "improvements" that people are so sure about.
There are so many examples of "Hey I can compile my own kernel. Let's make some changes without knowing what they do, and hear a fantastic improvement!". That is just nonsense and voodoo. Everything named something related to realtime is popular. Sure, sometimes a reatime kernel is needed, basically when a given system sometimes responds too slowly to some events with a standard kernel. The SB Touch runs both gui and playback on a single weak cpu. That configuration might need a realtime kernel to never have a glitch at high samplerates. But a raspberry is much (much!) faster and easily handles audio playback on a standard kernel. Then the realtime kernel is not an improvement, rather the opposite.
Audio Diff maker seems like a completely worthless way of testing. There are too many ways that this method can fail and generate ghost differences, I would simply not trust if for anything.
Any difference that can be heard, can also be measured. And our ears aren't all that great, so we can easily measure much smaller differences than we can hear. All with "stupid test signals".
The voodoo-people always expect everyone to take their word for the fantastic improvements they achieve. No matter how absurd the claim is, if you question it, the standard answer is something along the lines of "Try it yourself, if you haven't tried it you should not write anything". I have never bothered doing that, but if I did and could not hear a difference, then I'm sure that would be argued to be because I didn't want to hear a difference, that my ears aren't good enough, or my hifi system isn't good enough. I have seen all these "explanations" in other threads.
Imagine doing science the same way. Let's say I have a laser lab with a high power laser. I claim that I can turn water into ice by irradiating it with a strong laser pulse. I could not take a picture of it because the ice melted too quickly. Other researchers are obviously questioning this result as it goes against current theory. My response then is that they should try it themselves. When they do and fail, I claim that this is because their lasers aren't good enough.
This is obvioulsy not how it works. If someone claims something controversial, they must present proof to be taken seriously. Nobody would even bother trying to reproduce my ice experiment, and I would most likely have trouble finding funding after that.
There are so many examples of "Hey I can compile my own kernel. Let's make some changes without knowing what they do, and hear a fantastic improvement!". That is just nonsense and voodoo. Everything named something related to realtime is popular. Sure, sometimes a reatime kernel is needed, basically when a given system sometimes responds too slowly to some events with a standard kernel. The SB Touch runs both gui and playback on a single weak cpu. That configuration might need a realtime kernel to never have a glitch at high samplerates. But a raspberry is much (much!) faster and easily handles audio playback on a standard kernel. Then the realtime kernel is not an improvement, rather the opposite.
Audio Diff maker seems like a completely worthless way of testing. There are too many ways that this method can fail and generate ghost differences, I would simply not trust if for anything.
Any difference that can be heard, can also be measured. And our ears aren't all that great, so we can easily measure much smaller differences than we can hear. All with "stupid test signals".
The voodoo-people always expect everyone to take their word for the fantastic improvements they achieve. No matter how absurd the claim is, if you question it, the standard answer is something along the lines of "Try it yourself, if you haven't tried it you should not write anything". I have never bothered doing that, but if I did and could not hear a difference, then I'm sure that would be argued to be because I didn't want to hear a difference, that my ears aren't good enough, or my hifi system isn't good enough. I have seen all these "explanations" in other threads.
Imagine doing science the same way. Let's say I have a laser lab with a high power laser. I claim that I can turn water into ice by irradiating it with a strong laser pulse. I could not take a picture of it because the ice melted too quickly. Other researchers are obviously questioning this result as it goes against current theory. My response then is that they should try it themselves. When they do and fail, I claim that this is because their lasers aren't good enough.
This is obvioulsy not how it works. If someone claims something controversial, they must present proof to be taken seriously. Nobody would even bother trying to reproduce my ice experiment, and I would most likely have trouble finding funding after that.
No problem Papalius, i' ve used Polipo but, IMHO, all sounds "dull" and i've never used anymore.
Hi HenrikEnquist,
What about having a third party evaluate the sound quality?
Does anyone here at diyAudio have a reputation for sound quality ratings?
Can you introduce me to someone you trust?
Let him/her decide how to evaluate and the evaluation environment.
If you need a comparison, let them decide on that as well.
And if there has been no change in sound quality, I will correct my erroneous assertions and apologize to everyone who has seen this thread.
What about having a third party evaluate the sound quality?
Does anyone here at diyAudio have a reputation for sound quality ratings?
Can you introduce me to someone you trust?
Let him/her decide how to evaluate and the evaluation environment.
If you need a comparison, let them decide on that as well.
And if there has been no change in sound quality, I will correct my erroneous assertions and apologize to everyone who has seen this thread.
Hi Soundcheck,
many thanks for stepping in and speaking out about these issues, i really appreciate it.
Information about symphonic-mpd, a distribution for Raspberry Pi4.
It has been developed to target audiophile who want high quality music playback on I2S output.
Official Forum
symphonic-mpd
If you are interested, please ask your questions in this thread.
In order to use the SD images of this distribution, you need to join the official forum.
If you would like to join, please email me below with your handle name.
symphonic.mpd@gmail.com
kubotayo@jcom.home.ne.jp
mark.create@gmail.com
Hi papalius!
How to stream UPNP from Minimserver to Symphonic mpd. Thanks
Not sure I understand your question correctly. Do you mean if there is someone we can ask to listen and compare an optimized and a standard software setup, and I would accept the result as proof that there is a difference? In that case, no.
One important problem is that "sound quality" is a very vague parameter. Do you mean perceived quality? That is a very uncertain parameter that is affected by many things, including mood and expectations. I don't trust my own ears very far on this, and certainly not somebody elses.
Also there isn't a clear connection between accuracy and perceived quality. For example, add a little second order distorsion, and many people will think it sounds better. Psychoacoustics is a large and complicated field, let's not go there..
I'm interested in reproducible measurements that shows that the changes do what they are claimed to do. For example, it's relatively easy to measure the influence of clock jitter. It's one of the parameters an Audio Precision anaylser gives you. Let's start with the jitter given by the MASH function of the PLL. This one is clearly a problem and I have no reason to doubt anyone claiming they can hear it. It should show up nicely on a test. That one is bad enough that it can probably be seen also with much simpler equipment than an AP.
If the other optimizations meant to decrease jitter really do that, it should also show up in a measurement. If no difference can be seen by running all the possible tests, then either there simply is no difference, or the difference is so small it drowns in the noise floor.
soundcheck knows very well that what he says is not true.
His touch toolbox consisted of hw-related tweaks (disabling the screen when playing, power supply mods, etc.), and OS-related tweaks, some of which recommended the lowest latency possible (minimal alsa buffers, thus requiring setting real-time priorities) - see section "1.4 Alsa (Linux soundlayer) Buffer Tuning" of his now-deleted blog post soundcheck's - audio@vise: soundcheck's Squeezebox Touch Toolbox 2.0
I did dispute these latency tweaks which were the very same thing as here in this thread.
e.g.
https://www.diyaudio.com/forums/pc-based/93315-linux-audio-176.html#post2404920
or
https://www.diyaudio.com/forums/pc-based/93315-linux-audio-121.html#post1856411
I do not think anyone ever disputed the logical HW-related changes including disabling the display backlight (presumably powered by a high-voltage converter easily producing audible noise and measured in spectrum). I do not remember any measuring spectrum of the touch but the HW tweaks (incl. the software-based HW tweaks such as disabling the backlight) could easily change the measured spectrum. Yet it had nothing to do with the timing "improvements" I did, do, and always will question as unlogical and unsupported by any evidence of better parameters.
His touch toolbox consisted of hw-related tweaks (disabling the screen when playing, power supply mods, etc.), and OS-related tweaks, some of which recommended the lowest latency possible (minimal alsa buffers, thus requiring setting real-time priorities) - see section "1.4 Alsa (Linux soundlayer) Buffer Tuning" of his now-deleted blog post soundcheck's - audio@vise: soundcheck's Squeezebox Touch Toolbox 2.0
I did dispute these latency tweaks which were the very same thing as here in this thread.
e.g.
https://www.diyaudio.com/forums/pc-based/93315-linux-audio-176.html#post2404920
or
https://www.diyaudio.com/forums/pc-based/93315-linux-audio-121.html#post1856411
I do not think anyone ever disputed the logical HW-related changes including disabling the display backlight (presumably powered by a high-voltage converter easily producing audible noise and measured in spectrum). I do not remember any measuring spectrum of the touch but the HW tweaks (incl. the software-based HW tweaks such as disabling the backlight) could easily change the measured spectrum. Yet it had nothing to do with the timing "improvements" I did, do, and always will question as unlogical and unsupported by any evidence of better parameters.
I tried the touch toolbox but did not recognise any difference after all. At first I thought I did. But it was probably based on "hope" 
Henrik, when you say "For example, it's relatively easy to measure the influence of clock jitter.", do you mean measuring on the analog output or on some internal interface?
//
Henrik, when you say "For example, it's relatively easy to measure the influence of clock jitter.", do you mean measuring on the analog output or on some internal interface?
//
Yes on the analog output. If you do a high resolution frequency analysis of a single frequency test tone, the jitter will produce sidebands. If the jitter is random phase noise, this adds shoulders to the peak in the spectrum. The MASH-function seems to be jumping between two PLL settings at some frequency, so that most likely would show up as isolated sidebands at fixed intervals. An AP analyzer can use this kind of measurement to show a spectrum of the jitter as well as the amplitude.
Is it just software calculation from FFT results or does it need a dedicated HW? I mean if a regular software analyzer could implement such feature. Thanks.
I think you can do it by just analysing a recorded waveform, with no special HW (apart from the fact that you need to record using something that has a very good SNR and doesn't have too much own jitter). I haven't looked into the exact math though. And it's quite possible that the AP system uses some tricks to improve the results.
are you joking....???
(..*sigh*... i said it again)
please don´t be so dishonest, Henrik. papalius´ pictures in post #84 clearly show the
reduction of jitter caused by the MASH funktion in smpd.
and you can´t just go around and demand measurements with some expensive professionell
equipment. diyAudio is not a EE-forum, it´s for hobbyists. the most of us can´t afford
thausands of $ or € for test-equipment. but if you are really interrested i measurements
you can easily do it yourself, smpd is free afterall and you can set it up in 10 minutes.
..and btw... just because you don´t trust your ears doesn´t mean that others can not.
no one who designs comercial audio-gear disputes the validity of listening-tests.
they all know that meaasurements are just a design-tool (..or for advertising).
it´s audio, and in order to know if its any good, you have to actually listen to it.
and alot of criteria of soundquality are objectivly quantifiable, like width and depth of
the soundstage, separation of intruments or the focus of microdetails, etc.
(... do i really have to explain all this ?...)