Hi, TNT
I'm not sure what you mean by that, but are you curious about the effect of network load on sound quality?
Then you need to look at the network stack of the Linux kernel.
Because there are a lot of inefficiencies there, and for hardware like the Raspberry Pi, they're negligible.
Of course, it's my favorite. The next thing I'm going to tackle is the kernel bypass of the network stack.
I'm not sure what you mean by that, but are you curious about the effect of network load on sound quality?
Then you need to look at the network stack of the Linux kernel.
Because there are a lot of inefficiencies there, and for hardware like the Raspberry Pi, they're negligible.
Of course, it's my favorite. The next thing I'm going to tackle is the kernel bypass of the network stack.
i think after the colourful but rude coment about your forum he was comparing
smpd with audiophile network-swiches (which are of course utter nonsenes,
like expensive usb-cables or expensives cables in general)
Hi M_Balou,
Thanks for the commentary.
I see, I understand.
I don't care if he was rude in his comments.
I'm sure I've been rude.
Above all, it's natural to be frustrated by the lack of technical basis and objective measurement results.
Some of the members of my forum will be offended, but I admonish them not to act short-sightedly so as not to be a nuisance to those viewing this thread.
When we replace a component, whether it's just a change in bandwidth balance or an improvement in quality, that's very important.
As far as cables are concerned, if we confirm that the insulation material used for sheathing is fluorocarbon resin, and if we select a cable that has a vibration countermeasure for the electrical contacts, there is no major failure.
The vibrations of the contacts can also be addressed on their own.
Sound quality comparison reviews that focus solely on the wire material are often inconsistent.
It's not too late to replace a network switch, even after we've confirmed that the switch is a bottleneck.
When it comes to network switches, the products themselves are
Bottlenecks are rare, and in most cases the bottleneck is caused by network settings at the router and at both ends of the network (receiver and sender).
Rather than replacing a network switch, it is more effective to review the network settings while looking at the logs.
Thanks for the commentary.
I see, I understand.
I don't care if he was rude in his comments.
I'm sure I've been rude.
Above all, it's natural to be frustrated by the lack of technical basis and objective measurement results.
Some of the members of my forum will be offended, but I admonish them not to act short-sightedly so as not to be a nuisance to those viewing this thread.
When we replace a component, whether it's just a change in bandwidth balance or an improvement in quality, that's very important.
As far as cables are concerned, if we confirm that the insulation material used for sheathing is fluorocarbon resin, and if we select a cable that has a vibration countermeasure for the electrical contacts, there is no major failure.
The vibrations of the contacts can also be addressed on their own.
Sound quality comparison reviews that focus solely on the wire material are often inconsistent.
It's not too late to replace a network switch, even after we've confirmed that the switch is a bottleneck.
When it comes to network switches, the products themselves are
Bottlenecks are rare, and in most cases the bottleneck is caused by network settings at the router and at both ends of the network (receiver and sender).
Rather than replacing a network switch, it is more effective to review the network settings while looking at the logs.
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.
I2S signal Yellow: LRCK, Red: DATA, Blue: BCK
volumio2 Hifiberry-dac driver (DAC slave) 5us
volumio2 Hifiberry-dac driver (DAC slave) 10ns
symphonic-mpd v0.8.x hifiberry-dac driver (DAC slave) 10ns
symphonic-mpd v0.8.x hifiberry-dacplus driver (DAC master) 10ns
This was taken with an older version (v0.8.x for RPi3).
Here's a comparison between volumio2 and symphonic-mpd.
I2S signal Yellow: LRCK, Red: DATA, Blue: BCK
volumio2 Hifiberry-dac driver (DAC slave) 5us
volumio2 Hifiberry-dac driver (DAC slave) 10ns
symphonic-mpd v0.8.x hifiberry-dac driver (DAC slave) 10ns
symphonic-mpd v0.8.x hifiberry-dacplus driver (DAC master) 10ns
This was taken with an older version (v0.8.x for RPi3).
papalius: I do not think anyone disputes that a different configuration of the bit clock PLL circuit can yield different/better jitter. This is technically completely sound and logical. Again, your change would be likely welcomed by the RPi community, many configurations rely on RPi-generated clock.
I just installed the symphonic-mpd on my RPI3 with FIFOPI and DDDAC. I got it to work with RPI-DAC. Should I set the default sample rate to S24?
So far the radio stations sounded fine!
The interface works well and efficient. What I wonder is how I could get this to work with other streaming services than Spotify. With so much effort and time spent building this, would it not make more sense to enable the "HIFI" streaming services?
Or is there a way and have I not found it yet?
So far the radio stations sounded fine!
The interface works well and efficient. What I wonder is how I could get this to work with other streaming services than Spotify. With so much effort and time spent building this, would it not make more sense to enable the "HIFI" streaming services?
Or is there a way and have I not found it yet?
Hi Robin,
The "default sample rate" in the SOUND CARD configuration screen in the web UI is the setting that shairport-sync and spotifyd are referring to.
If you are using an I2S input to a homemade DAC board instead of a HAT, there may be a discrepancy between the FS of the driver specified by dtoverlay and the FS expected by the DAC chip, and the sound may not be produced.
In such a case, you can specify S24 or S32 according to the specifications of the DAC chip to select the appropriate FS to produce sound.
When you need to convert to S24 or S32 in mpd, set the "SoX Resampler Format" on the MPD setting screen.
Can you play back the "SoX Resampler Format" on the MPD setting screen as the default setting?
If so, the "default sample rate" on the SOUND CARD setting screen should remain at the default setting and should not cause any problems with playback.
Thank you for your question about support for streaming services.
In the previous version (v0.9.x) for RPi3, the implementation of the automatic shutdown of unwanted processes was difficult It was complicated.
This made it very difficult to support the new music playback software.
The new version (v1.0.x) for RPi4 allows us to implement this feature smartly. Now that I have, it is practical to support other music playback software.
Please tell us the specific streaming services you want to use. We would like to consider whether we can support it.
The "default sample rate" in the SOUND CARD configuration screen in the web UI is the setting that shairport-sync and spotifyd are referring to.
If you are using an I2S input to a homemade DAC board instead of a HAT, there may be a discrepancy between the FS of the driver specified by dtoverlay and the FS expected by the DAC chip, and the sound may not be produced.
In such a case, you can specify S24 or S32 according to the specifications of the DAC chip to select the appropriate FS to produce sound.
When you need to convert to S24 or S32 in mpd, set the "SoX Resampler Format" on the MPD setting screen.
Can you play back the "SoX Resampler Format" on the MPD setting screen as the default setting?
If so, the "default sample rate" on the SOUND CARD setting screen should remain at the default setting and should not cause any problems with playback.
Thank you for your question about support for streaming services.
In the previous version (v0.9.x) for RPi3, the implementation of the automatic shutdown of unwanted processes was difficult It was complicated.
This made it very difficult to support the new music playback software.
The new version (v1.0.x) for RPi4 allows us to implement this feature smartly. Now that I have, it is practical to support other music playback software.
Please tell us the specific streaming services you want to use. We would like to consider whether we can support it.
Hi papalius,
That are some interesting images, not quite that, what i would have expected.
so, the difference in signal-quality between different software is much bigger
than the the difference between master or slave mode, right?
and i don´t know if read the picture with the measure from Volumio right,
so the doubled lines on the edges of the signals (when it shifts from 0 to 1 or from 1 to 0 )
are the phase-shift of the signal, but phaseshift is practical phasenoise aka Jitter,
and when the gridlines are 10 nanoseconds apart you have a shift of ca. 2,8 nanoseconds.
(distance of th gridlines is 50 pixels in the picture and distance of the lines is in aveverage 14 pixels)
i mean, it can´t be really THAT bad, because jitter is usually measured in picoseconds !!
on the other hand the difference between master and slave mode isn´t so big,
it even gets covered up partly by the background noise.
it would be interesting to see a measure from Volumio in master mode...
i wonder, if maybe the PLL of the rasberry isn´t so bad after all, and the real reason for
the bad quality of I2S output is a poorly optimised OS...
papalius, could you please tell us which oscilloscope was used ?
Hi M_Balou,
I am told that this image was measured with a RIGOL DS1054Z.
The person making the measurements is the designer and developer of DAC HAT.
Probing with an oscilloscope is an advanced technique in itself, but I have complete faith in his skills.
Before you hear my take on this, here are some assumptions.
According to the Compute Module datasheet, the oscillator on the Raspberry Pi has a cycle-cycle jitter of 20 picoseconds, and for the clock generated by the PLL, the cycle-cycle jitter is at the level of 48 picoseconds.
Raspberry Pi oscillator (19.2 MHz on the Pi3 and 54 MHz on the Pi4).
There are five PLLs hanging around, providing a clock for the various peripherals.
Each of the five types of PLLs is used as follows
PLLA ... unused in the RPi3 and used for something in the RPi4.
PLLB ...used for CPU clock only
PLLC ... Used for clocks in GPUs, SDRAMs, etc.
PLLD ... used in peripherals such as I2S (500 MHz by default)
PLLH ... used in peripherals such as HDMI
The clock used in I2S is obtained by fractionalizing PLLD (500 MHz).
For example, to generate a BCLK 2,822,400Hz for a 44.1 KHz sound source, RPi3 can be used to generate Two frequencies, 2,808,988Hz and 2,824,858Hz, are combined in a specific ratio to It generates a BCLK of 2,822,400Hz.
If we simply turn off MASH, RPi3 produces a BCLK of 2,824,858 Hz and It causes a change in pitch and a change in playback speed. (For those who don't have absolute pitch, the changes in pitch are just something you get used to while listening to the music. and sensitive to changes in tempo, which is unacceptable to most people.)
There are two things that I am acutely aware of throughout the development
The first is that for the hardware to perform properly, it needs to be configured correctly for its intended use.
The Raspberry Pi is a versatile hardware and many of its default settings do not take into account the quality of audio playback.
By properly initializing the hardware for a specific application, BCLK shake (a type of jitter) caused by MASH in the PLL can easily be countered.
Second, and more importantly, there is still a significant difference in sound quality between a DAC master and a DAC slave, even if there is little or no difference in oscilloscope observations.
Furthermore, we have experienced that the sound quality difference between the DAC master and the DAC slave can be reversed through software optimization.
In fact, the sound quality of a DAC slave with software optimization is higher than that of a DAC master without software optimization.
With USB audio, I think it's unlikely that such a noticeable difference would occur.
It is the USB receiver's job to provide the I2S signal to the DAC chip, and the weight that the receiver design gives to the sound quality is not small.
That's why it's interesting to work on I2S in a single board computer.
I am told that this image was measured with a RIGOL DS1054Z.
The person making the measurements is the designer and developer of DAC HAT.
Probing with an oscilloscope is an advanced technique in itself, but I have complete faith in his skills.
Before you hear my take on this, here are some assumptions.
According to the Compute Module datasheet, the oscillator on the Raspberry Pi has a cycle-cycle jitter of 20 picoseconds, and for the clock generated by the PLL, the cycle-cycle jitter is at the level of 48 picoseconds.
Raspberry Pi oscillator (19.2 MHz on the Pi3 and 54 MHz on the Pi4).
There are five PLLs hanging around, providing a clock for the various peripherals.
Each of the five types of PLLs is used as follows
PLLA ... unused in the RPi3 and used for something in the RPi4.
PLLB ...used for CPU clock only
PLLC ... Used for clocks in GPUs, SDRAMs, etc.
PLLD ... used in peripherals such as I2S (500 MHz by default)
PLLH ... used in peripherals such as HDMI
The clock used in I2S is obtained by fractionalizing PLLD (500 MHz).
For example, to generate a BCLK 2,822,400Hz for a 44.1 KHz sound source, RPi3 can be used to generate Two frequencies, 2,808,988Hz and 2,824,858Hz, are combined in a specific ratio to It generates a BCLK of 2,822,400Hz.
If we simply turn off MASH, RPi3 produces a BCLK of 2,824,858 Hz and It causes a change in pitch and a change in playback speed. (For those who don't have absolute pitch, the changes in pitch are just something you get used to while listening to the music. and sensitive to changes in tempo, which is unacceptable to most people.)
There are two things that I am acutely aware of throughout the development
The first is that for the hardware to perform properly, it needs to be configured correctly for its intended use.
The Raspberry Pi is a versatile hardware and many of its default settings do not take into account the quality of audio playback.
By properly initializing the hardware for a specific application, BCLK shake (a type of jitter) caused by MASH in the PLL can easily be countered.
Second, and more importantly, there is still a significant difference in sound quality between a DAC master and a DAC slave, even if there is little or no difference in oscilloscope observations.
Furthermore, we have experienced that the sound quality difference between the DAC master and the DAC slave can be reversed through software optimization.
In fact, the sound quality of a DAC slave with software optimization is higher than that of a DAC master without software optimization.
With USB audio, I think it's unlikely that such a noticeable difference would occur.
It is the USB receiver's job to provide the I2S signal to the DAC chip, and the weight that the receiver design gives to the sound quality is not small.
That's why it's interesting to work on I2S in a single board computer.
Last edited:
Those pictures show difference in PLL signal generated by different configurations of internal RPi oscillators. Some configurations produce lower jitter, some higher. Since RPi does not have a facility for producing good-quality audio clock, a proper external clock clocking the slaved PCM interface is used in proper installations.
Those pictures have nothing to do with any data processing on the RPi.
Last edited:
Please either present some facts, or stop spreading this claim on this forum and do so within your club. You have yourself said that you were not able to measure any change in jitter produced by your software optimizations. Then you present some clearly jittery pictures and then say that software processing improves the sound. Those less involved in audio will get a feeling that your software processing samples to the I2S which has absolutely no technical foundation to improve anything does actually fix the jitter they saw on the pictures.
This is a technical forum, diy, not a religious club.
Hi phofman,
Thanks for the comment.
I'm not particularly interested in the changes before and after the PLL setting change, as it's obvious.
As you say, it's a problem already solved in DAC master.
Let's discuss something more technically interesting here, something unresolved and exciting.
By the way, have you tried any software changes?
Have you noticed any changes in sound quality after trying it out?
And have you ever tried it but didn't notice any change in sound quality at all?
Tell us a few things you've actually tried.
Let's discuss those topics.
I think it would be easy to explain my experience and I'm sure it would be interesting.
Thanks for the comment.
I'm not particularly interested in the changes before and after the PLL setting change, as it's obvious.
As you say, it's a problem already solved in DAC master.
Let's discuss something more technically interesting here, something unresolved and exciting.
By the way, have you tried any software changes?
Have you noticed any changes in sound quality after trying it out?
And have you ever tried it but didn't notice any change in sound quality at all?
Tell us a few things you've actually tried.
Let's discuss those topics.
I think it would be easy to explain my experience and I'm sure it would be interesting.
Last edited:
In my projects the things I deal with are several magnitudes below audability. I measure the differences, every change is checked against measurements. But my changes are DSP-based and have direct effect on the sample values (no matter how tiny the changes are).
You keep talking about "better sound". That alone tells you have no rigorous methodology for determining effects of your changes because "better" is no specification. Sure you can talk about your experience, but I care only about objective measures which confirm a change to generally accepted improvement indicators (lower noise floor, lower IMD, lower THD, blind listening tests confirming a change is audible, etc.). I do not care about excited claims how your software "improves the sound" and how your club members appraise the results. Those are just empty words without any technical value.
But since apparently you have done no telling measurements or other objective tests plus you have not shown a single piece of code there is nothing for a serious technical discussion.
You keep talking about "better sound". That alone tells you have no rigorous methodology for determining effects of your changes because "better" is no specification. Sure you can talk about your experience, but I care only about objective measures which confirm a change to generally accepted improvement indicators (lower noise floor, lower IMD, lower THD, blind listening tests confirming a change is audible, etc.). I do not care about excited claims how your software "improves the sound" and how your club members appraise the results. Those are just empty words without any technical value.
But since apparently you have done no telling measurements or other objective tests plus you have not shown a single piece of code there is nothing for a serious technical discussion.
Hi phofman,
Thanks for your reply.
Great project.
I'm well aware of your stance on objectivity, so I can easily imagine that the DSP products you make are of a high quality that will be widely accepted by your users.
We have members in the club who use digital channel dividers and DSP boards, so They should be highly interested in your project. (Maybe some members have already used it.)
What I use as a development metric are statistics about the activity inside the software.
Those stats have allowed me to develop more efficiently, but they are nowhere near the objective sound quality metrics that you are measuring.
Everything I say about sound quality in this thread is subjective, so please don't worry too much about it.
Thanks for your reply.
Great project.
I'm well aware of your stance on objectivity, so I can easily imagine that the DSP products you make are of a high quality that will be widely accepted by your users.
We have members in the club who use digital channel dividers and DSP boards, so They should be highly interested in your project. (Maybe some members have already used it.)
What I use as a development metric are statistics about the activity inside the software.
Those stats have allowed me to develop more efficiently, but they are nowhere near the objective sound quality metrics that you are measuring.
Everything I say about sound quality in this thread is subjective, so please don't worry too much about it.