The content of this thread is my personal opinion and does not represent performance based on objective metrics.
Information about symphonic-mpd, a CRAFTED LINUX 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
Information about symphonic-mpd, a CRAFTED LINUX 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.
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
Last edited:
Hello diyAudio community,
I have been a member of symphonic-mpd (smpd) community since last year. Let me add a little bit about smpd as I can't stress enough how BRILLIANT smpd is!
Now, smpd v1 has been released for RPi 4 and I would like to encourage you to try the great music player.
As smpd was developed by Paparius-san in Japan, we have done most discussion in Japanese. However, as the community wants to let the world know smpd, we are working hard to publish important and fundamental information of smpd in English in our community.
smpd is another Linux music player distribution running on Raspberry Pi like Vomulio, moOde and RuneAudio etc. But, what makes smpd unique is its concept. Paparius-san, the developer, has focused on sound quality more than anybody in the world!
Probably the below link is what smpd is explained the best as the first point.
symphonic-mpdの世界 (The world of Symphonic MPD) | symphonic-mpd
At the moment, smpd is NOT generally available for everyone. To keep the high quality of the software and reasonable audience community, the community is membership basis. If you are interested in smpd, please contact email addresses Paparius-san explained in his post above.
I have been a member of symphonic-mpd (smpd) community since last year. Let me add a little bit about smpd as I can't stress enough how BRILLIANT smpd is!
Now, smpd v1 has been released for RPi 4 and I would like to encourage you to try the great music player.
As smpd was developed by Paparius-san in Japan, we have done most discussion in Japanese. However, as the community wants to let the world know smpd, we are working hard to publish important and fundamental information of smpd in English in our community.
smpd is another Linux music player distribution running on Raspberry Pi like Vomulio, moOde and RuneAudio etc. But, what makes smpd unique is its concept. Paparius-san, the developer, has focused on sound quality more than anybody in the world!
Probably the below link is what smpd is explained the best as the first point.
symphonic-mpdの世界 (The world of Symphonic MPD) | symphonic-mpd
At the moment, smpd is NOT generally available for everyone. To keep the high quality of the software and reasonable audience community, the community is membership basis. If you are interested in smpd, please contact email addresses Paparius-san explained in his post above.
Hi, M_Balou
symphonic-mpd is a distribution of aarch64 based on LFS (Linux From Scratch).
All the software that we configure is built with Raspberry Pi4 (Cortex-A72) specific build options and configured to have minimal functionality.
The downside of being LFS-based is that it doesn't have a good package management system like Arch or debian.
If you want to add the software, you need to build it from the source.
However, we do provide pre-built packages for additional software that many users have requested.
The unique symphonic-mpd package management command "app" has a similar interface to apt and yum.
symphonic-mpd is a distribution of aarch64 based on LFS (Linux From Scratch).
All the software that we configure is built with Raspberry Pi4 (Cortex-A72) specific build options and configured to have minimal functionality.
The downside of being LFS-based is that it doesn't have a good package management system like Arch or debian.
If you want to add the software, you need to build it from the source.
However, we do provide pre-built packages for additional software that many users have requested.
The unique symphonic-mpd package management command "app" has a similar interface to apt and yum.
Code:
root [ ~ ]# app --help
symphonic-mpd app installer
Usage: app <command> [<args>]
showcase Lists available packages.
list Lists installed packages.
search <app> Searches the repository for the specified package.
install <app> Download and install the specified package.
remove <app> Uninstalls the specified package.
show <app> Displays the details of installed packages.
hash <app> Print hash.I have been using SMPD for well over a year, first on RPI3 and now RPI4 on an IanCanada stack and am pleased with how it works. You will find the support is first class and personal. Just follow Papalius's
instructions for joining the forum.
I have never bothered to look under the hood to see which distro it is based on.
instructions for joining the forum.
I have never bothered to look under the hood to see which distro it is based on.
Hm, whenever I see a combination of words "audiophile" and "linux distribution", I always get cautious...
Please let me ask a few questions:
At the same time there is a screenshot
I see some chart with nanosecond figures, while at the same time the table says period-size 147 frames at 44.1kHz. The latency induced by the period part of the buffer alone is 147/44.1kHz = 3.3ms. IIUC the quote is comparing interrupt latency in your chart (microseconds) to playback-chain latency specified by the other linux distributions (milliseconds). Do you have any idea why?
The PCM audio interface of RPi described on pages 138+ of https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711/rpi_DATA_2711_1p0.pdf has input and output FIFOs 64 ints long (i.e. 32 stereo frames). Default settings in the I2S driver linux/bcm2835-i2s.c at rpi-5.6.y * raspberrypi/linux * GitHub specify the PCM interface will issue a DMA request to copy one frame (max_bursts = 2 linux/bcm2835-i2s.c at rpi-5.6.y * raspberrypi/linux * GitHub times 4 bytes linux/bcm2835-i2s.c at rpi-5.6.y * raspberrypi/linux * GitHub ) from the alsa buffer to the I2S 32-bit register BCM2835_I2S_FIFO_A_REG when the fill drops below 48 (0x30), i.e. 24 stereo frames. The FIFO is clocked out at PCM_FS and PCM_CLK rate, not dependent on any latency setup.
Even if the driver was modifed to throw the DMA request at 0 fill (causing the FIFO underruns constantly), the FIFO is still there and no amount (or lack of) of software latency can influence timing and data values of the output I2S signal. Changing the latency can only influence buffer underruns/overruns = data corruption from the sound-quality POW.
Please let me ask a few questions:
At the same time there is a screenshot
I see some chart with nanosecond figures, while at the same time the table says period-size 147 frames at 44.1kHz. The latency induced by the period part of the buffer alone is 147/44.1kHz = 3.3ms. IIUC the quote is comparing interrupt latency in your chart (microseconds) to playback-chain latency specified by the other linux distributions (milliseconds). Do you have any idea why?
The PCM audio interface of RPi described on pages 138+ of https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711/rpi_DATA_2711_1p0.pdf has input and output FIFOs 64 ints long (i.e. 32 stereo frames). Default settings in the I2S driver linux/bcm2835-i2s.c at rpi-5.6.y * raspberrypi/linux * GitHub specify the PCM interface will issue a DMA request to copy one frame (max_bursts = 2 linux/bcm2835-i2s.c at rpi-5.6.y * raspberrypi/linux * GitHub times 4 bytes linux/bcm2835-i2s.c at rpi-5.6.y * raspberrypi/linux * GitHub ) from the alsa buffer to the I2S 32-bit register BCM2835_I2S_FIFO_A_REG when the fill drops below 48 (0x30), i.e. 24 stereo frames. The FIFO is clocked out at PCM_FS and PCM_CLK rate, not dependent on any latency setup.
Even if the driver was modifed to throw the DMA request at 0 fill (causing the FIFO underruns constantly), the FIFO is still there and no amount (or lack of) of software latency can influence timing and data values of the output I2S signal. Changing the latency can only influence buffer underruns/overruns = data corruption from the sound-quality POW.
Attachments
Last edited:
Hi, phofman
Thank you for pointing this out.
The comparison to playback latency was my misreading and was not appropriate.
What symphonic-mpd is focusing on is the correlation between interrupt latency and sound quality.
Therefore, we have corrected the description to compare the interrupt latency with the typical interrupt latency of a distribution using a typical kernel/RT kernel.
The frequency and duration of CPU, memory, and various peripheral activities can be deduced from the interrupt latency.
And such internal transport activity can cause noise, jitter, ground swings, and bursty voltage fluctuations that affect the D/A conversion.
I use interrupt latency and various profile data measurements to drive the elimination of unneeded activity for playback without side effects.
Note that max_bursts, BCM2835_I2S_TX, and BCM2835_I2S_TX_PANIC have been tuned in symphonic-mpd.
In addition, since the transfer data must exist in the L2 cache to increase the efficiency of the burst transfer, prefetching is performed in the driver according to the transfer cycle.
Hi, Skip Pack
I'm sorry.
In symphonic-mpd, the USB output is not optimized in any way.
Not only that, it also uses libusb and hub-ctrl to stop all USB ports when booting the OS.
Thank you for pointing this out.
The comparison to playback latency was my misreading and was not appropriate.
What symphonic-mpd is focusing on is the correlation between interrupt latency and sound quality.
Therefore, we have corrected the description to compare the interrupt latency with the typical interrupt latency of a distribution using a typical kernel/RT kernel.
The frequency and duration of CPU, memory, and various peripheral activities can be deduced from the interrupt latency.
And such internal transport activity can cause noise, jitter, ground swings, and bursty voltage fluctuations that affect the D/A conversion.
I use interrupt latency and various profile data measurements to drive the elimination of unneeded activity for playback without side effects.
Note that max_bursts, BCM2835_I2S_TX, and BCM2835_I2S_TX_PANIC have been tuned in symphonic-mpd.
In addition, since the transfer data must exist in the L2 cache to increase the efficiency of the burst transfer, prefetching is performed in the driver according to the transfer cycle.
Hi, Skip Pack
I'm sorry.
In symphonic-mpd, the USB output is not optimized in any way.
Not only that, it also uses libusb and hub-ctrl to stop all USB ports when booting the OS.
papalius: Thanks for your answer. Still I do not see how all of this affects the jitter of the output I2S signal in a controlled way. Have you done any measurements for long term PCM_CLK/PCM_FS jitter improvement of a specific configuration for master mode, or PCM_OUT noise component for slave mode being improved by your changes in a consistent way?
Can I see the modified GPL sources? Thanks. I am trying to learn RPi4 limits for high-speed I2S, this is an important topic for me.
Can I see the modified GPL sources? Thanks. I am trying to learn RPi4 limits for high-speed I2S, this is an important topic for me.
Hi, phofman
Even minor changes in the software on the transport can make a difference in the sound quality, so it's natural to assume that there will be some difference in the output after the D/A conversion.
However, the J-Test has not been successful in capturing that change.
Either it's buried in the noise floor, or a level change so small that you don't care is what you're looking for, or it's nonsense to focus on the frequency domain in the first place, but either way, we don't have a way to measure it accurately.
We apologize for not being able to disclose the measurement data as you might expect.
Also, the high-speed I2S you are working on seems to be of a different nature than the timing accuracy improvements that symphonic-mpd focuses on, so our technology is unlikely to help you.
At symphonic-mpd, we believe that our success was due in part to the fact that we were not fixated on the time-varying voltage of the I2S signal, but rather on the basis of developing an indicator that was observable, repeatable, and sensitive to minor software changes.
Even minor changes in the software on the transport can make a difference in the sound quality, so it's natural to assume that there will be some difference in the output after the D/A conversion.
However, the J-Test has not been successful in capturing that change.
Either it's buried in the noise floor, or a level change so small that you don't care is what you're looking for, or it's nonsense to focus on the frequency domain in the first place, but either way, we don't have a way to measure it accurately.
We apologize for not being able to disclose the measurement data as you might expect.
Also, the high-speed I2S you are working on seems to be of a different nature than the timing accuracy improvements that symphonic-mpd focuses on, so our technology is unlikely to help you.
At symphonic-mpd, we believe that our success was due in part to the fact that we were not fixated on the time-varying voltage of the I2S signal, but rather on the basis of developing an indicator that was observable, repeatable, and sensitive to minor software changes.
Sorry, I will not comment on such claim.
I still do not understand what timing regarding the D/A conversion you can make more precise with your software changes in RPi4.
Interesting, what observable, repeatable, and sensitive indicator is that if as you say you cannot measure the changes?
This is an important question. Does symphonic-mpd include modified GPL code? If yes that code must absolutely be made available.
...so, i downloaded the image and put it on my rpi, and its really great!
No connection problems, the web-UI is neat and straightforward.
Altogether smpd actually looks like a finished product.
And spmd sounds really nice too, althougt i only had the chance to listen for an hour yesterday.
Cheerio,
Mirko
No connection problems, the web-UI is neat and straightforward.
Altogether smpd actually looks like a finished product.
And spmd sounds really nice too, althougt i only had the chance to listen for an hour yesterday.
Cheerio,
Mirko
Hi, Mirko
Thank you very much for your feedback.
It is known that the initial setting of symphonic-mpd does not start normally in rare cases.
I'm happy to say that I was able to get the sound right.
The official forum documentation is written for v0.9.6 for RPi3.
We have just released v0.1.x for RPi4 and volunteers are just starting to work on the documentation.
If you have any questions, you can ask them in the official forum or in this thread.
Thank you very much for your feedback.
It is known that the initial setting of symphonic-mpd does not start normally in rare cases.
I'm happy to say that I was able to get the sound right.
The official forum documentation is written for v0.9.6 for RPi3.
We have just released v0.1.x for RPi4 and volunteers are just starting to work on the documentation.
If you have any questions, you can ask them in the official forum or in this thread.
Hi, HenrikEnquist
The SD images of symphonic-mpd include a variety of open software, including the GPL, and the works of the symphonic-mpd Research and Development Club, which I organize.
The smpd R&D Club works contain two kernel modules that serve as engines for music playback.
If you are of the opinion that kernel modules should also be strictly GPL-covered, we offer the following options
In other words, we provide an SD image with these kernel modules removed.
Spotify Connect will be able to produce sound with only the modification of spotifyd.conf.
shairport-sync and mpd can be sounded out if you enable the ALSA backend, rebuild it, and change the conf file appropriately.
The SD images of symphonic-mpd include a variety of open software, including the GPL, and the works of the symphonic-mpd Research and Development Club, which I organize.
The smpd R&D Club works contain two kernel modules that serve as engines for music playback.
If you are of the opinion that kernel modules should also be strictly GPL-covered, we offer the following options
In other words, we provide an SD image with these kernel modules removed.
Spotify Connect will be able to produce sound with only the modification of spotifyd.conf.
shairport-sync and mpd can be sounded out if you enable the ALSA backend, rebuild it, and change the conf file appropriately.
Hi, phofman
If you argue that "transport does not change the sound quality", then the symphonic-mpd will seem worthless to you.
In fact, there are some listening environments where the sound changes due to transport differences cannot be discerned.
It could be that they are being taken care of properly on the processing pathway or that there is a bigger bottleneck on the processing pathway.
On the other hand, I have experienced as a matter of fact that there are playback environments where transport differences can make a huge difference in playback sound.
The motivation for the development of symphonic-mpd is to solve this bottleneck.
They have no interest in letting each other argue their points.
Just be aware that there are people who are working on improving sound quality with this kind of approach.
If you argue that "transport does not change the sound quality", then the symphonic-mpd will seem worthless to you.
In fact, there are some listening environments where the sound changes due to transport differences cannot be discerned.
It could be that they are being taken care of properly on the processing pathway or that there is a bigger bottleneck on the processing pathway.
On the other hand, I have experienced as a matter of fact that there are playback environments where transport differences can make a huge difference in playback sound.
The motivation for the development of symphonic-mpd is to solve this bottleneck.
They have no interest in letting each other argue their points.
Just be aware that there are people who are working on improving sound quality with this kind of approach.
