The request from the PhileWeb member should have been granted. It doesn't matter if it's before 1.0. Is that still the case, a year and a half later?
I think "organization" is vague enough that pretty much any club/coorporation etc qualifies (but I'm no laywer so don't trust that statement unconditionally).
The part I can't understand is why you want to keep it hidden. The kernel modules might be interesting for someone else for a different purpose. Do you believe that you improve the quality by keeping the software secret? That's plain wrong, the opposite is true. Or so you just not want to share?
Remember that your entire project would be impossible if it wasn't for the great efforts of a lot of people in the open source community.
Hi, HenrikEnquist
Thank you very much for your detailed comments on the GPL.
Unfortunately, we were unable to find any examples of the use of the GPL within the club, so we have decided to request a formal response from the FSF(licensing@fsf.org).
Here's what we contacted them about
Upon receipt of a response from the FSF, we are committed to immediately revising the club's operating rules based on that response.
Please suspend any discussion of the GPL until we receive a response from the FSF.
Thank you very much for your detailed comments on the GPL.
Unfortunately, we were unable to find any examples of the use of the GPL within the club, so we have decided to request a formal response from the FSF(licensing@fsf.org).
Here's what we contacted them about
Upon receipt of a response from the FSF, we are committed to immediately revising the club's operating rules based on that response.
Please suspend any discussion of the GPL until we receive a response from the FSF.
Hi, TNT
I'm a real audiophile, really.
If there is an improvement, it is the sound quality.
We prioritize sound quality over all features.
Are you curious about the specific implementation? Or are you more interested in the process by which this product was made?
We implemented a variety of ideas and culled the ideas by measuring and listening.
Over 2000 kernel builds, over 100 version upgrades, and a variety of experiments that I can't even begin to describe here, over a period of three years, we've trimmed away anything that would compromise the sound quality.
This is what the process is all about.
And if you need an explanation of implementation, what this product doesn't have is what I've carved out for sound quality so far.
It is possible to describe each one of the things I have taken away. If you'll just take the time to do it.
I'm a real audiophile, really.
If there is an improvement, it is the sound quality.
We prioritize sound quality over all features.
Are you curious about the specific implementation? Or are you more interested in the process by which this product was made?
We implemented a variety of ideas and culled the ideas by measuring and listening.
Over 2000 kernel builds, over 100 version upgrades, and a variety of experiments that I can't even begin to describe here, over a period of three years, we've trimmed away anything that would compromise the sound quality.
This is what the process is all about.
And if you need an explanation of implementation, what this product doesn't have is what I've carved out for sound quality so far.
It is possible to describe each one of the things I have taken away. If you'll just take the time to do it.
Hi, phofman
I think they are trying to keep unnecessary things other than I2S signals out as much as possible.
However, we have not been able to capture an objective electrical change in the I2S signal to prove it.
Therefore, we are unable to prepare an answer that satisfies you.
Capturing the differences in electrical signals is a very important topic and one that I have a great interest in.
If we succeed in doing so, the improvement in sound quality should be achieved through a more efficient process.
I think they are trying to keep unnecessary things other than I2S signals out as much as possible.
However, we have not been able to capture an objective electrical change in the I2S signal to prove it.
Therefore, we are unable to prepare an answer that satisfies you.
Capturing the differences in electrical signals is a very important topic and one that I have a great interest in.
If we succeed in doing so, the improvement in sound quality should be achieved through a more efficient process.
Hi, soundcheck
I've seen your blog.
I've never seen a site with such a comprehensive introduction to RPi configuration.
I can see now that you have spent a tremendous amount of time on this subject.
I would like to thank you for introducing me to your blog.
There's very little I can advise you on, but I might be able to point you to a couple of tweaks for piCore.
One is about sched_load_balance.
Next, about NIC offload.
Lastly, about vm.stat_interval.
I've seen your blog.
I've never seen a site with such a comprehensive introduction to RPi configuration.
I can see now that you have spent a tremendous amount of time on this subject.
I would like to thank you for introducing me to your blog.
There's very little I can advise you on, but I might be able to point you to a couple of tweaks for piCore.
One is about sched_load_balance.
Next, about NIC offload.
Lastly, about vm.stat_interval.
Thx for the flowers and advise.
Though I'd expect a lot if these options won't add anything to the overall result - on my system setup.
I removed a lot of OS tweaks over time that I've been using in the early days (Touch-Toolbox).
Anyhow. I'll have a look at your hints.
And one more general comment.
The main goal IMO is to make the system more efficient. To eliminate the
bumps in the road.
Some people still havn't understood that we ? don't go after "low latency".
Low latency can be a byproduct of higher system efficiency though.
Example. If you make the Alsa buffer very small you'll get lowest latency,
however the IRQs are skyrocketing. And that's not good from an system efficiency
perspective either. It's all about finding the best compromise.
One of my key findings to improve system efficiency during playback is using a large RAM buffer
where the fully bulk-decoded audio file gets stored prior of being streamed to
the OS soundlayer.
Unfortunately you can't do that with MPD. With squeezelite you can do it though.
Perhaps you guys add squeezelite to your portfolio on day. I'll for sure have a look at your OS, since
I'm also running an ALARM AARCH64 (kernel and userland) rt system.
Enjoy.
Though I'd expect a lot if these options won't add anything to the overall result - on my system setup.
I removed a lot of OS tweaks over time that I've been using in the early days (Touch-Toolbox).
Anyhow. I'll have a look at your hints.
And one more general comment.
The main goal IMO is to make the system more efficient. To eliminate the
bumps in the road.
Some people still havn't understood that we ? don't go after "low latency".
Low latency can be a byproduct of higher system efficiency though.
Example. If you make the Alsa buffer very small you'll get lowest latency,
however the IRQs are skyrocketing. And that's not good from an system efficiency
perspective either. It's all about finding the best compromise.
One of my key findings to improve system efficiency during playback is using a large RAM buffer
where the fully bulk-decoded audio file gets stored prior of being streamed to
the OS soundlayer.
Unfortunately you can't do that with MPD. With squeezelite you can do it though.
Perhaps you guys add squeezelite to your portfolio on day. I'll for sure have a look at your OS, since
I'm also running an ALARM AARCH64 (kernel and userland) rt system.
Enjoy.
Last edited:
Hi, soundcheck
Thank you for your reply.
Perhaps I am the one who understands what you are saying very well.
To take your efforts further, you'll need to make modifications to the source of each piece of software.
In the end, memory access itself remains as a major bottleneck as the effort continues to erase bumps in the road.
To remove this bottleneck, we must improve the CPU cache hit rate and reduce memory access as much as possible.
You were also concerned about the increase in IRQ.
Hardware interrupts and software interrupts, each of which requires different countermeasures, but beyond those countermeasures, you'll notice the inefficient side of ALSA libraries and ALSA drivers.
Because for every one period of replay, you're generating tons of memory accesses, tons of system calls, register reads, and a disgusting amount of context switches.
After taking them away, there is the symphonic-mpd.
Thank you for your reply.
Perhaps I am the one who understands what you are saying very well.
To take your efforts further, you'll need to make modifications to the source of each piece of software.
In the end, memory access itself remains as a major bottleneck as the effort continues to erase bumps in the road.
To remove this bottleneck, we must improve the CPU cache hit rate and reduce memory access as much as possible.
You were also concerned about the increase in IRQ.
Hardware interrupts and software interrupts, each of which requires different countermeasures, but beyond those countermeasures, you'll notice the inefficient side of ALSA libraries and ALSA drivers.
Because for every one period of replay, you're generating tons of memory accesses, tons of system calls, register reads, and a disgusting amount of context switches.
After taking them away, there is the symphonic-mpd.
I very well understand that tuning apps is another step forward.
I am actually running my own squeezelite version, which has some additional enhancements inside, btw.
Once more. It's always the sum of features that makes a solution a solution.
And I can imagine that you brought it w/ MPD as base a bit further.
My suggestion to isolate CPU0 to avoid combining IRQ load and app load is another
point.
Running the audio app or even just the output thread on a isolated "exclusive" CPU is another one of my key ingredients.
I have been running benchmarking tests to prove that point.
Fixing the CPU clock to a certain frequency and disabling the governors is another one.
By coincidence I figured that these tweaks solve another issue:
Without doing above you can't achieve flawless GBit UDP speeds on a PI4.
Yep. There a numerous areas to look at. And the situation changes from day to day with every update.
And btw.
Nothing makes an OS "audiophile" or "symphonic".
These are pure marketing terms.
All we have are more or less efficient OSs.
The DACs makes the music. Not the OS.
Enjoy.
I am actually running my own squeezelite version, which has some additional enhancements inside, btw.
Once more. It's always the sum of features that makes a solution a solution.
And I can imagine that you brought it w/ MPD as base a bit further.
My suggestion to isolate CPU0 to avoid combining IRQ load and app load is another
point.
Running the audio app or even just the output thread on a isolated "exclusive" CPU is another one of my key ingredients.
I have been running benchmarking tests to prove that point.
Fixing the CPU clock to a certain frequency and disabling the governors is another one.
By coincidence I figured that these tweaks solve another issue:
Without doing above you can't achieve flawless GBit UDP speeds on a PI4.
Yep. There a numerous areas to look at. And the situation changes from day to day with every update.
And btw.
Nothing makes an OS "audiophile" or "symphonic".
These are pure marketing terms.
All we have are more or less efficient OSs.
The DACs makes the music. Not the OS.
Enjoy.
Hi, soundcheck
In symphonic-mpd, CPU0, CPU1, and CPU2 are isolated.
CPU0 is IRQ and kernel thread, CPU1 is Xenomai kernel, CPU2 is music playback software, and CPU3 is others.
We fix the affinity and priority of the main threads in taskset and chrt and, if necessary, POSIX API.
I also enabled force_turbo in the kernel with CPU governor disabled and fixed arm_freq at 1188MHz.
1188, what this number means is for another time.
Thank you very much for your suggestion about the speed of UDP.
I was not at all aware of that.
It may be just an OS for you, but it's a precious child for me. The music he plays gives me courage.
In symphonic-mpd, CPU0, CPU1, and CPU2 are isolated.
CPU0 is IRQ and kernel thread, CPU1 is Xenomai kernel, CPU2 is music playback software, and CPU3 is others.
We fix the affinity and priority of the main threads in taskset and chrt and, if necessary, POSIX API.
I also enabled force_turbo in the kernel with CPU governor disabled and fixed arm_freq at 1188MHz.
1188, what this number means is for another time.
Thank you very much for your suggestion about the speed of UDP.
I was not at all aware of that.
It may be just an OS for you, but it's a precious child for me. The music he plays gives me courage.
Sure, let's wait for their answer. Please post the entire answer when you get it.
You are making a very big effort to try to avoid publishing the sources. I already asked this before but got no answer, please don't ignore the question again.
Why don't you want to provide the source code?
Hi, HenrikEnquist
Thank you for your question.
I've avoided answering that question, but please forgive me.
I think the reason for this is probably due to my mental weakness.
I've become unsatisfied with enjoying this hobby on my own.
I wanted to have a few friends who could share this value with me.
This objective has been achieved.
I have a few friends who are happy with this software.
But in my arrogance, I was tempted to hide the ugly scars of failure behind the software.
I feared the shame of being accused of that patchy, dirty source.
To keep me motivated for the development, I wanted a quiet retreat where I could be at peace and not be disturbed by anything.
From a developer who values the spirit of open source, I can only take the blame.
It's not like I'm using their accomplishments, but I'm refusing to give back.
Several people who have become aware of this software at diyAudio have asked to join the smpd R&D Club.
If they are happy with the symphonic-mpd, I'm happy.
I'll be discussing the future with my friends who have planned to introduce the software on diyAudio.
At least until I get a response from the FSF, I'll be here to enjoy the discussion with my like-minded friends.
Thank you for your question.
I've avoided answering that question, but please forgive me.
I think the reason for this is probably due to my mental weakness.
I've become unsatisfied with enjoying this hobby on my own.
I wanted to have a few friends who could share this value with me.
This objective has been achieved.
I have a few friends who are happy with this software.
But in my arrogance, I was tempted to hide the ugly scars of failure behind the software.
I feared the shame of being accused of that patchy, dirty source.
To keep me motivated for the development, I wanted a quiet retreat where I could be at peace and not be disturbed by anything.
From a developer who values the spirit of open source, I can only take the blame.
It's not like I'm using their accomplishments, but I'm refusing to give back.
Several people who have become aware of this software at diyAudio have asked to join the smpd R&D Club.
If they are happy with the symphonic-mpd, I'm happy.
I'll be discussing the future with my friends who have planned to introduce the software on diyAudio.
At least until I get a response from the FSF, I'll be here to enjoy the discussion with my like-minded friends.
Hi, DUC985
If you are using a USB DAC, other transports may be suitable.
Because the USB output and USB receiver bypass is the starting point for the symphonic-mpd.
However, it is possible to use the previous version (v0.9.6) for RPi3.
No future maintenance is planned and support is limited, but maybe it can help you.
Which driver does Allos USBridge specify in dtoverlay?
If you are using a USB DAC, other transports may be suitable.
Because the USB output and USB receiver bypass is the starting point for the symphonic-mpd.
However, it is possible to use the previous version (v0.9.6) for RPi3.
No future maintenance is planned and support is limited, but maybe it can help you.
Which driver does Allos USBridge specify in dtoverlay?
I very well understand that tuning apps is another step forward.
I am actually running my own squeezelite version, which has some additional enhancements inside, btw.
Once more. It's always the sum of features that makes a solution a solution.
And I can imagine that you brought it w/ MPD as base a bit further.
My suggestion to isolate CPU0 to avoid combining IRQ load and app load is another
point.
Running the audio app or even just the output thread on a isolated "exclusive" CPU is another one of my key ingredients.
I have been running benchmarking tests to prove that point.
Fixing the CPU clock to a certain frequency and disabling the governors is another one.
By coincidence I figured that these tweaks solve another issue:
Without doing above you can't achieve flawless GBit UDP speeds on a PI4.
Yep. There a numerous areas to look at. And the situation changes from day to day with every update.
And btw.
Nothing makes an OS "audiophile" or "symphonic".
These are pure marketing terms.
All we have are more or less efficient OSs.
The DACs makes the music. Not the OS.
Enjoy.
wow, i just had a revelation !!
i testet almost all audio-distros for the pi in the months and i can´t understand
why dietpi sounds so freaking good, when it´s just a normal distro and
not designed for Audio.
detpi isn´t really a real distro, it´s just rasbian striped down to the bare
minimum and optimised for efficiency and speed (...for gaming, video-streaming,etc.)
i run mpd on dietpi with 48mb RAM, 15 tasks, 78 threads and 0,02% load.
it´s so obvious, once you realise it !
and it proofs the validity of the claim, because when a non-audiohlie OS designed
with the same principles in mind can achive the same soundquality, it must be
the right way to do it.
I don't think you need to be worried about that. Let's imagine you have published you project on github. Who will actually read the code? Mostly people who are interested in the project and are curious of the inner workings. Some might just be looking for ideas for other projects. Others might fork it to make their own version by including some of their own ideas for improvements. If those work out well they might submit their changes back to you, as a request to include in your version. You are free to do what you want with such requests, you are not forced to accept. But in most cases these will have some useful idea behind them.
Very few people (none most likely) would read the code and contact you to complain about the code being ugly. Fights mostly happen in big projects where many people collaborate and end up disagreeing on some major change.
The way I see it you would lose nothing by publishing, but you might gain. And if you think that your code isn't "nice enough" to be useful to others, just don't worry. Most people aren't interested in copy-pasting code into their own projects. It's much more useful to just see how others have solved things, and just use the idea behind something rather than the code itself.
Hi, HenrikEnquist
Thank you very much for taking the time to share your thoughts.
Your opinion is encouraging to me.
I will proceed to prepare the source for publication.
The membership club will continue as is, but I'll be happy to provide it to any member who asks for source disclosure.
I was afraid to copy and paste superficial sources.
The idea behind it is what I want you to see.
However, that code, which is ugly at first glance, makes the idea behind it difficult to understand.
It's ugly for a reason. It's because we prioritize being more effective over code portability and readability above all else.
There is a reason for that ugliness, one by one, and it can be explained.
For me, who understands what led to that form, these codes are full of functional beauty.
Someone who understands the idea behind it and realizes the beauty of these codes is the friend I'm really looking for.
Thank you very much for taking the time to share your thoughts.
Your opinion is encouraging to me.
I will proceed to prepare the source for publication.
The membership club will continue as is, but I'll be happy to provide it to any member who asks for source disclosure.
I was afraid to copy and paste superficial sources.
The idea behind it is what I want you to see.
However, that code, which is ugly at first glance, makes the idea behind it difficult to understand.
It's ugly for a reason. It's because we prioritize being more effective over code portability and readability above all else.
There is a reason for that ugliness, one by one, and it can be explained.
For me, who understands what led to that form, these codes are full of functional beauty.
Someone who understands the idea behind it and realizes the beauty of these codes is the friend I'm really looking for.
Hi, M_Balou
Is there a problem with the operation of the SMPD?
If you have any questions, please feel free to contact us.
Firmware updates to the built-in EEPROM are recommended for the Raspberry pi4.
The EEPROM has the firmware for the bootloader and VL805 USB controller installed.
If necessary, we will guide you through the process of updating to the recommended version.
Related to the topic of firmware, are you experiencing any problems with over temperature or under voltage?
In the dashboard of the Web UI, there is an alert display column. It is recommended that you check to see if there are any alerts of over temperature or under voltage being recorded there.
Lastly, there is a setting item called "Process cut-down" in the NETWORK setting screen of Web UI.
Please let us know if you are running RPi with a fixed IP address.
The following is a detailed explanation of the limitations of setting this item to "extreme".
Is there a problem with the operation of the SMPD?
If you have any questions, please feel free to contact us.
Firmware updates to the built-in EEPROM are recommended for the Raspberry pi4.
The EEPROM has the firmware for the bootloader and VL805 USB controller installed.
If necessary, we will guide you through the process of updating to the recommended version.
Related to the topic of firmware, are you experiencing any problems with over temperature or under voltage?
In the dashboard of the Web UI, there is an alert display column. It is recommended that you check to see if there are any alerts of over temperature or under voltage being recorded there.
Lastly, there is a setting item called "Process cut-down" in the NETWORK setting screen of Web UI.
Please let us know if you are running RPi with a fixed IP address.
The following is a detailed explanation of the limitations of setting this item to "extreme".
This is good news! You will not regret sharing the code. It will make it possible for the club members to give much better feedback, and even suggestions for improvements.
Start like that, and then after some time maybe you decide to make it publicly available
Hi papalius,
Thanks for asking, i really appreciate it
..and sorry for not responding earlier, i was distracted this afternoon watching the SpaceX lifestream...
so, yes, i had problems with the bootloader.
I intstalled the new 5.4 kernel with dietpi on this RPI4 (i have only this one) 2 weeks ago, so i had already
a fairly new EEPROM-file, but when i first ran SMPD all worked fine, friday i tried out the new 64bit rasbian
and it installed the latest bootloader, after that SMPD didn´t boot properly, the first time was fine, but
after a reboot it was gone, after i booted the rpi without a sd-card, the bootloaer somehow resetet and
SMPD worked again, but only for 1 time again.
so. i did some reading on the rasberry-github to konw how this EEPROM thing works...
i just swapped out the "fixup4cd.dat" and "start4cd.elf" form the /boot folder with the newer ones,
and SMPD woks fine again !
is ist possible to do an "apt install" for the rpi-eeprom package on SMPD in order to keep the bootlloader
up to date ?
and maybe you should consider including rpi-update in SMPD.
and, yes, i checked out the "Process cut-down" settings. andd now the rpi is on fixed IP, because the
"extreme" setting kills the avahi/zeroconf service, right? ...anoher little deamon we don´t really need,
i´m fine with that !
BTW, how do i get rid of spotify and airplay? i don´t need that either...
Temperatur is fine, settling in at 47,7°C, i have small heatsinks on the CPU and RAM,
and no Undervoltage, the rpi is fed by a benchsupply, so plenty of power (still working on the final PSU...)
actually, the rpi with SMPD draws about 50mA less current than any other Distro i tried,
thats really neat !
cheerio,
Balou
Hi, M_Balou
Thank you for your reply.
To check the EEPROM version with symphonic-mpd, run the following command.
The recommended version for SMPD is as follows.
When updating to the recommended version
If you have more recent firmware installed than the recommended version, please consider reverting to the recommended version.
To revert to the recommended (but slightly older) version, use the following command.
The RPi4's firmware is frequently updated on a weekly basis.
While improvements continue to be made primarily to reduce power consumption and heat generation, the firmware released on 11/18/2019 supports a feature called Dynamic Voltage and Frequency Scaling (DVFS), which significantly changes the clock calculation logic for COREs and GPUs.
When the arm_freq, core_freq, PLL frequency, etc. are set to a fixed value like symphonic-mpd, it conflicts with DVFS and the clock is not set to the expected value.
If you don't mind reverting to a slightly older firmware, we recommend reverting to the version recommended by SMPD.
The process cutdown is a function of what you say it is.
If extreme is specified, mDNS is disabled. Also, SSH will be stopped while music is playing.
Regarding Spotify Connect, unless you set up a premium account in the web UI settings screen, auto-launch remains disabled. It will not be activated automatically.
In addition, it is AirPlay(shairport-sync), but this also does not need to be particularly concerned about this because this will automatically stop the process when you start playing music.
In addition, the Web UI (ympd) also terminates the process when you close the browser and the session ends, ympd terminates the process by itself and listens for HTTP requests with systemd's socket activation.
This also eliminates websocket communication between the browser and ympd and polling between ympd and mpd.
Thank you for your reply.
To check the EEPROM version with symphonic-mpd, run the following command.
The recommended version for SMPD is as follows.
When updating to the recommended version
If you have more recent firmware installed than the recommended version, please consider reverting to the recommended version.
To revert to the recommended (but slightly older) version, use the following command.
The RPi4's firmware is frequently updated on a weekly basis.
While improvements continue to be made primarily to reduce power consumption and heat generation, the firmware released on 11/18/2019 supports a feature called Dynamic Voltage and Frequency Scaling (DVFS), which significantly changes the clock calculation logic for COREs and GPUs.
When the arm_freq, core_freq, PLL frequency, etc. are set to a fixed value like symphonic-mpd, it conflicts with DVFS and the clock is not set to the expected value.
If you don't mind reverting to a slightly older firmware, we recommend reverting to the version recommended by SMPD.
The process cutdown is a function of what you say it is.
If extreme is specified, mDNS is disabled. Also, SSH will be stopped while music is playing.
Regarding Spotify Connect, unless you set up a premium account in the web UI settings screen, auto-launch remains disabled. It will not be activated automatically.
In addition, it is AirPlay(shairport-sync), but this also does not need to be particularly concerned about this because this will automatically stop the process when you start playing music.
In addition, the Web UI (ympd) also terminates the process when you close the browser and the session ends, ympd terminates the process by itself and listens for HTTP requests with systemd's socket activation.
This also eliminates websocket communication between the browser and ympd and polling between ympd and mpd.