• These commercial threads are for private transactions. diyAudio.com provides these forums for the convenience of our members, but makes no warranty nor assumes any responsibility. We do not vet any members, use of this facility is at your own risk. Customers can post any issues in those threads as long as it is done in a civil manner. All diyAudio rules about conduct apply and will be enforced.

symphonic-mpd

Thanks. I try it but it not run

Hi Duanbui,

You're using v1.0.3 (RPi4), right?
There should be a way to make it work, so get a member to help you troubleshoot.

Do you see any errors?

After you have tried to play it for a while, open the SUPPORT web UI.

You will see a link called support_log.tar.gz, download it and save it to your PC.

This is a compressed version of the journal logs and other major logs.

Send it to symphonic.mpd@gmail.com and we'll see if you get any errors.
 
Don't worry. And I shouldnt have replied so late in the evening when I was tired and a little grumpy..


Anyway, just to show how this could work, I simulated some spectra with different amounts and types of jitter. It's done quickly and just to give an idea of how it works. I haven't paid any proper attention to the amounts of jitter so don't look at the levels, just the shape.

okay, Hendrik,

my intention was to simply ignore you, because the previous "diskussion" was pretty much pointless.
but maybe we can still have decent conversation.

firstly, a little bit about my background: i´m an "audiophie" in th literal sense of the word,
just enjoing listening to my beloved musik and i´m diy-ing my audio-gear for my whole
adult life. i´m not an audio-engineer not even an EE, but i´m not illiterate, i work as an
eletrician in the maintenance in the automotive industrie for over 30 years.
CNC machines are way more complicatet than any of the audio-stuff...

and you must keep in mind that none of us in this diskussion is a native english speaker
(which i think is actually kind of awesome.... )
so definitions can sometimes gat a little fuzzy.


so, back to the topic:
...yeah, i totally get what you are trying to do (did it in the firrst place), of course you can
measure jitter by analyzing the sprectrum of an testsignal on the output of the dac.
but it´s a flawed method, because by measuring the analog signal you are introducing a
device to the chain which behaviour you can´t predict. different dacs have different means
of jitter-reduction, you don´t even know if it reacts linear.
it´s like measuring the THD of an amp by pointing a microphone at the speaker.
it´s just not accurate.

AFAIK the frequency change in MASH mode is immediate, first you have a short pulse, than
a longer pulse.

DimDim did an article about this back in the day, when the raspberry was new:
The Raspberry Pi: Audio out through I2S | Dimdim's Blog
 
Hi @papalius and friends, how can I get UPNP for Symphonic MPD (running on Pi3B+)?

hi bác, (copy ở cùng thread).

Here is the way how to install upmpdcli in SMPD.

1. Activate port 6000
edit /lib/systemd/system/mpd.socket as follows to enable port 6600.

# for Web UI
ListenStream=%t/mpd/socket
# for Any other mpd clients
ListenStream=6600

2. Install the upmpdcli related libraries.

app install jsoncpp
app install libmicrohttpd
app install libupnpp
app install npupnp
app install upmpdcli

3. Create upmpdcli.conf.

#
# (Reference) /etc/upmpdcli.conf setting
#
#mpdhost = 127.0.0.1 (default)
#mpdport = 6600 (default)
friendlyname = SymphonicMPD (Any renderer name)
checkcontentformat = 0
openhome = 1
lumincompat = 1
ohproductroom = SymphonicMPD
ohmetapersist = 1
logfilename=/var/log/upmpdcli.log (Specifies that it should be logged)
loglevel = 3 (It won't start if you get a level 1 error)

4. Add to mpd.conf lines below.

#
# Setting of /etc/mpd.conf (Added the following)
#
input {
plugin "curl"
# proxy "127.0.0.1:8123" (No polipo in use, comment in)
}

5. Create a user named "upmpdcli" as it doesn't work as root.

useradd upmpdcli
touch /var/cache/upmpdcli

6. Confirm it's working properly.

upmpdcli -D -c /etc/upmpdcli.conf -l 1

7. Register upmpdcli to systemd.

- Cteate file
touch /lib/systemd/system/upmpdcli.service

- Edit
#
# (Reference)/lib/systemd/system/upmpdcli.service setting
#

[Unit]
Description=UPnP Renderer front-end to MPD
After=network.target mpd.service

[Service]
Type=simple
# Note: if start fails check with "systemctl status upmpdcli"
ExecStart=/usr/bin/upmpdcli -c /etc/upmpdcli.conf

Restart=always
RestartSec=1min

[Install]
WantedBy=multi-user.target

- Confirm
cat /lib/systemd/system/upmpdcli.service

8. Start and activate the upmpdcli.service

systemctl daemon-reload (Load the created umpdcli.service)
systemctl start upmpdcli.service (Simple activation, now you can use it)
systemctl enable upmpdcli.service (Activate at boot time, you can use it always)
 
Yes, you're right, the difficulties are there. I'm not at all sure I can implement it well.

What you want to address is the pre-rising part of the sound.
That's where I think the fact that the fundamental and overtones rise at the same time would be a good marker.
You mean that when for example there is a drum beat, you would analyze the waveform to figure out the time where many harmonics start, and then consider the stuff before that as the pre-ringing? That should work for simple isolated signals, but I'm not sure it has any chance of working in the mess of a music waveform. I was looking at the waveforms for different drum beats yesterday, and they are messier than I first thought. In most cases there isn't a clear first transient. Even if they sound sharp, most of them look more like random noise that increases quickly for a millisecond or so. I looked at a bunch, and none of those had something at the start that looked like a pre-ringing.


Indeed, it may be a waste of time to tackle areas we can't hear.
But DACs, amplifiers, and speakers, whether they are in the audible range or not, and whether they are real or not, strive to be faithful to the input.
It's a waste of the amplifier's superior braking power and the speaker's superior responsiveness to be consumed by the reproduction of pre-ringing.

It makes more sense to order the DAC to play less pre-ringing waves than it does to order the DAC to play pre-ringing waves.
This would improve the quality of the audible range.
Or would it not improve the quality of the audible range?
I realize that I didn't write that last part very well so it doesn't say what I actually meant. Let me try again:
I think the only sure way to get rid of the pre-ringing, is to low-pass filter with a less steep filter, sacrificing some of the higher frequencies. This in practice turns the probably inaudible 22050 Hz signal into a high-frequency attenuation that we (or at least some of us) probably can hear. This doesn't seem like a useful trade-off.



And I agree that removing a useless signal is a good thing, even if the useless signal in itself is inaudible. As soon as you have some nonlinearity somewhere in the chain (dac, amplifier, speaker...) you get all the intermodulation products, for example the pre-ringing togehter with a 20kHz signal gives a distorsion peak at a very audible 2050 Hz. How large a problem this is will depend on too many things so I wouldn't dare to give a strong opinion on whether it can ever be audible or not, but at least in theory the effect is clearly there.
 

TNT

Member
Joined 2003
Paid Member
Looking at post #141 and #142, this thread is an obvious try to lure in new members to a "club" which use licensed software in a way it was not intended. The "club" tries/claims to circumvent the need for sharing the source code. Also, the technical foundation(s?) that this project is founded on seems at least, shaky - and probably based on hope and guessing.

//
 
...yeah, i totally get what you are trying to do (did it in the firrst place), of course you can
measure jitter by analyzing the sprectrum of an testsignal on the output of the dac.
but it´s a flawed method, because by measuring the analog signal you are introducing a
device to the chain which behaviour you can´t predict. different dacs have different means
of jitter-reduction, you don´t even know if it reacts linear.
it´s like measuring the THD of an amp by pointing a microphone at the speaker.
it´s just not accurate.
The method has limitations of course, like every other measurement method. But in many cases it's the only possible way. Some dac chips have built in jitter reduction techniques yes, which means measuring the jitter on the clock input won't give you the actual jitter in the sample clock. That information is only available inside the chip itself, where you have no way of reaching it.
And in any case, measuring the clock jitter on the clock input pin of the dac (which I assume is what you want to do) is far from trivial. Let's ignore the really big mash jitter which is easy to measure. We really want to measure in the picosecond range (ideally sub-picosecond). So using any normal oscilloscope is simply out of the question. They are much too slow, and too inaccurate. So we get something like this: https://teledynelecroy.com/oscilloscope/labmaster-10-zi-a-oscilloscopes
Then we can get down something like 5 ps accuracy. Still not as good as we want, but that's not the only problem.

Just hooking up a probe to the traces on the board changes the electrical properties of the system so much that what you are measuring isn't even they way it usually performs.



AFAIK the frequency change in MASH mode is immediate, first you have a short pulse, than
a longer pulse.

DimDim did an article about this back in the day, when the raspberry was new:
The Raspberry Pi: Audio out through I2S | Dimdim's Blog
Thanks, that gives some more details. So the 1kHz I used is much too slow. That will still give sidebands, but with a different distribution and with the main peaks much further apart.
 
Last edited:
Hi chauphuong,

In order to support UPnP with Pi2/3B(+), you will need another hardware (Pi2/3, apu1/2 or Intel machine) in addition to your Pi3B+.
The way to get UPnP support with your Pi3B+m, depends on the second hardware you have available. Please let us know which hardware you can use.

yo
 
Hi chauphuong,

In order to support UPnP with Pi2/3B(+), you will need another hardware (Pi2/3, apu1/2 or Intel machine) in addition to your Pi3B+.
The way to get UPnP support with your Pi3B+m, depends on the second hardware you have available. Please let us know which hardware you can use.

yo

Hi. Thanks for the question. I want to use Raspberry Pi as UPNP renderer for Minimserver installed on PC, and to play Qubuz and Tidal from BubbleUPNP installed on Android phone.
 
Hi. Thanks for the question. I want to use Raspberry Pi as UPNP renderer for Minimserver installed on PC, and to play Qubuz and Tidal from BubbleUPNP installed on Android phone.

Hi chauphuong,

v0.9.6(RPi3) is based on Raspbian.
Try apt-get to install upnpdcli.

I don't know if any additional configuration is needed or not.
If it doesn't work, ask again.
I'll try to find out if any members are using UPnP with v0.9.6 (RPi3).
 
You mean that when for example there is a drum beat, you would analyze the waveform to figure out the time where many harmonics start, and then consider the stuff before that as the pre-ringing? That should work for simple isolated signals, but I'm not sure it has any chance of working in the mess of a music waveform. I was looking at the waveforms for different drum beats yesterday, and they are messier than I first thought. In most cases there isn't a clear first transient. Even if they sound sharp, most of them look more like random noise that increases quickly for a millisecond or so. I looked at a bunch, and none of those had something at the start that looked like a pre-ringing.


Hi HenrikEnquist,

Thank you for your profound insights.

I don't know if this can be implemented. No one knows the right answer, so I will have to do my own trial and error.

I'll save it for when I've worked through the topic I'm working on now, just for fun.

It was very useful to discuss this with you.
There's so much to do, there's never enough time to do it all.
I'm sure you do too.
 

TNT

Member
Joined 2003
Paid Member
Here is an oscilloscope screen capture of the well-known BCLK swing in I2S of raspberry pi.
Here's a comparison between volumio2 and symphonic-mpd.
<snip>
This was taken with an older version (v0.8.x for RPi3).

Can you confirm that the different level of "jitter" came not only from different software but also different hardware?

A higher clocked board would effect these measurement!?

It seems to be confirmed here:

The Raspberry Pi: Audio out through I2S | Dimdim's Blog

If the only thing you want is to get to the top of the mountain, why climb the side of it if you can take the bus up?

//
 
TNT: IMO that jitter is produced by the same HW, but using different configurations of the audio-suboptimal master clock generator of RPi. That configuration is a matter of software, but we both know that has nothing to do with any timing of processes.

Actually that configuration would be interesting and useful to see... but as you say, this thread is just a marketing thing.

BTW look at thread rating stars in the PC-Based section

Daphile 9, CamillaDSP 1, Peppy Player 1, piCorePlayer 1, PAXOR 1

And this thread after a few days without a single contribution to DIYaudio members: 2 :) Yeah right...
 
Hi chauphuong,

With Pi4B, it is possible to create a UPnP system with a single Pi4B. However, if you are using Pi2B/3B, you will need another Pi2B/3B.
As for the software to support UPnP with two Pi2B/3Bs, you will need to use rpi3-upnpgw and smpdplayer-i2s which have been developed by donuts.shop73. They are based on the SMPD and lightMPD source code. Rpi3-upnpgw is from lightMPD and smpdplayer-i2s from SMPD.

Information about these software programs can be found in
SMPD Home -> General Discussion -> Donuts Shop's Room
あなたのアカウントでログイン | symphonic-mpd

If you don't know how to use it, you can ask questions in the same place.

For more information on making the Pi4B UPNP, please see my reply #126 in this thread.
symphonic-mpd

yo
 
Last edited:
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.
I forgot to reply to this. I don't think doing a set of measurements with an AP is impossible. Of course I don't expect anyone to buy one. But this is a big forum, and there is a good chance that someone here knows someone who knows someone who has access to an AP unit. There was one in the EE department of my university for example, would expect that to be pretty normal.


It only needs to be done once, and should not take more than a few hours. If someone really wants to prove there is a difference, they could start by just asking around.