Yep. That's the right approach. Such a project overwhelms you in no time.
It'll become a full time job. If you can make a living from donations it might work out.
The bigger it gets though a 12hour day will no longer be sufficient to cover the full scope.
And change your wording. You improve the efficiency of a system, not the soundquality btw. It'd be perceived soundquality anyhow. And that depended on the quality of your audio device, environment and expectations. You just put yourself into a corner by continuing to talk about improving soundquality. You deliver a package and the users
will decide what they hear.
On modern highest quality DACs changes inside the OS become less and less relevant. If you still consider to go ahead look for a second mainstay. A 100% bet on efficiency alone will most probably make you fail.
Good luck.
Hi thanhvo31,
The source for openhome was made available to the public.
With a few libraries(glib, libxml, libxslt) built and a few modifications to the OpenHome Player's Makefile for aarch64, it looked like I could build it, but...
A large number of dependent library errors occurred late in the build
usr/bin/ld: cannot find -lSourceSongcast
I get about 20 errors like this.
If you install the dependent libraries one by one, I'm sure you'll be able to successfully build them at some point.
If you're willing to take the time to try, we can provide some support.
However, even if you do succeed in building it, whether or not you can get the sound out of the rtalsa/xsink driver is a different matter.
It may be easy to set up, or you may need to modify the source. This depends on how openhome is using the ALSA library.
By the way, RoonBridge was able to cope with the problem with a few source modifications. Squeezelite on the other hand has a hard time. openhome, well... I don't know.
If you're going to use the ALSA driver to produce sound instead of going through the rtalsa/xsink driver, then there's no advantage to using symphonic-mpd.
It's the same as running a low-latency kernel with the overhead of Xenomai kernel.
You can get good real-time performance only when you build your application with Xenomai API and RTDM.
Hi soundcheck,
Relax your shoulders.
You're listening to good sound in your own home, and that's fine.
It's not like you to bite me every time I say sound quality.
Whatever you want to call it, it's just a different way of putting it. Of course, I have no objection to you sticking to your word.
I know from your output that you've been working hard all along to make it sound good.
I'm very interested in you and I respect you.
So please, don't worry about how I describe it.
Again, it doesn't matter how you express it, it doesn't matter.
It's like you said, the user gets to judge it by their own ears.
I'm going to fail?
I can no longer count how many times I've failed to do so.
I hope to fail again and again in the future. Audio is a terrible thing. Everyone says different things and nothing has ever been absolutely right. I have to test everything myself.
Relax your shoulders.
You're listening to good sound in your own home, and that's fine.
It's not like you to bite me every time I say sound quality.
Whatever you want to call it, it's just a different way of putting it. Of course, I have no objection to you sticking to your word.
I know from your output that you've been working hard all along to make it sound good.
I'm very interested in you and I respect you.
So please, don't worry about how I describe it.
Again, it doesn't matter how you express it, it doesn't matter.
It's like you said, the user gets to judge it by their own ears.
I'm going to fail?
I can no longer count how many times I've failed to do so.
I hope to fail again and again in the future. Audio is a terrible thing. Everyone says different things and nothing has ever been absolutely right. I have to test everything myself.
Last edited:
Hi soundcheck,
I came up with one interesting idea, if you'll listen.
If you've listened to the symphonic-mpd and you like the sound quality of it, I'm free to describe it as whatever I want.
If you don't like the sound quality, I promise to delete the thread and get out of diyAudio by the end of the day.
What do you think? It's up to you whether you do it or not.
Your ears are the judge, and you can't lose.
If you say one word, "It sounds terrible," you win.
Don't bother to do a blind test. Just listen and judge it any way you want. Of course, you can blind test it, if you want.
I came up with one interesting idea, if you'll listen.
If you've listened to the symphonic-mpd and you like the sound quality of it, I'm free to describe it as whatever I want.
If you don't like the sound quality, I promise to delete the thread and get out of diyAudio by the end of the day.
What do you think? It's up to you whether you do it or not.
Your ears are the judge, and you can't lose.
If you say one word, "It sounds terrible," you win.
Don't bother to do a blind test. Just listen and judge it any way you want. Of course, you can blind test it, if you want.
Hi thanhvo31,
I have tried to build the dependent libraries.
As it turns out, it's not easy.
You need to prep some libraries that are missing from symphonic-mpd.
Since the openhome build script contains the old syntax of python You need to install python2. (You'll need to modify the source code to run it in python 3.
There is also a part of rsync to get the dependency files.
You need to build the following six and install some additional modules with pip at the end.
There are 5 openhome packages that should be built.
The ohPlayer is the final built playback software and the other four are dependent libraries.
The four dependent libraries were successfully built by changing the Makefile accordingly and removing errors.
The last one, ohPlayer, has some c++ errors and is not easy to fix.
My recommendation to you is to ask the openhome development team for aarch64 support.
Sorry I can't help you.
I have tried to build the dependent libraries.
As it turns out, it's not easy.
You need to prep some libraries that are missing from symphonic-mpd.
Since the openhome build script contains the old syntax of python You need to install python2. (You'll need to modify the source code to run it in python 3.
There is also a part of rsync to get the dependency files.
You need to build the following six and install some additional modules with pip at the end.
- glib
- libressl
- libxml2
- libxslt
- Python-2
- rsync
There are 5 openhome packages that should be built.
- ohdevtools
- ohNet
- ohNetGenerated
- ohPipeline
- ohPlayer
The ohPlayer is the final built playback software and the other four are dependent libraries.
The four dependent libraries were successfully built by changing the Makefile accordingly and removing errors.
The last one, ohPlayer, has some c++ errors and is not easy to fix.
My recommendation to you is to ask the openhome development team for aarch64 support.
Sorry I can't help you.
Last edited:
Thanks. But it seems that the author will accept no more new members since 17th July 2020 at 11:10 PM.
Am I an exception?
Thanks again. It seems a qualification step exists now, but the criteria is not disclosed.
I think I will wait until a new membership application will be accepted "unconditionally" as mentioned before.
Through reading the articles and posts in the past, I understand the club members are NOT entitled to ask for the source disclosure.
Some posts apparently written by the Japanese say that the Japanese members never ask for the source based on the Japanese common sense. They also say the behavior of "foreigners" is unpredictable. I do not feel comfortable to see such posts with prejudice still on the author's site.
I think I will wait until a new membership application will be accepted "unconditionally" as mentioned before.
Through reading the articles and posts in the past, I understand the club members are NOT entitled to ask for the source disclosure.
Some posts apparently written by the Japanese say that the Japanese members never ask for the source based on the Japanese common sense. They also say the behavior of "foreigners" is unpredictable. I do not feel comfortable to see such posts with prejudice still on the author's site.
Hi babalius,
I believe all posts here are at least for the common good purpose of promoting better audio reproduction system, although interpretation and thoughts around the purpose may vary sometimes greatly. What you are aiming at by your posting is unclear to say the least. If your priority is to denounce or defame someone rather than promoting the common good, then there is no place for you here.
I believe all posts here are at least for the common good purpose of promoting better audio reproduction system, although interpretation and thoughts around the purpose may vary sometimes greatly. What you are aiming at by your posting is unclear to say the least. If your priority is to denounce or defame someone rather than promoting the common good, then there is no place for you here.
Hi Babalius,
Why would you bother to post the github address papalius has been preparing for the source disclosure ? I can't see anything but malice to him.
The author has already stated that he will disclose the source code. I think the github address you linked to in this thread was prepared by him for that purpose.
Therefore, it would be wise to wait to discuss about source disclosure of SMPD until the author starts publishing.
I would be happy to recommend you as a member of the SMPD forum. However, there is a condition.
Some Japanese message boards are notorious internationally for their complete anonymity and the cesspools to post malicious content, unlike their Western counterparts. Some unscrupulous networkers are using this anonymous message boards to leak personal information. Of course, this is illegal even under Japanese law.
Do you swear that you have never done so? Please stop using diyAudio as a vile Japanese anonymous message boards.
Why would you bother to post the github address papalius has been preparing for the source disclosure ? I can't see anything but malice to him.
The author has already stated that he will disclose the source code. I think the github address you linked to in this thread was prepared by him for that purpose.
Therefore, it would be wise to wait to discuss about source disclosure of SMPD until the author starts publishing.
I would be happy to recommend you as a member of the SMPD forum. However, there is a condition.
Some Japanese message boards are notorious internationally for their complete anonymity and the cesspools to post malicious content, unlike their Western counterparts. Some unscrupulous networkers are using this anonymous message boards to leak personal information. Of course, this is illegal even under Japanese law.
Do you swear that you have never done so? Please stop using diyAudio as a vile Japanese anonymous message boards.
The now deleted repository had last commit on Dec 27, 2017:
GitHub - papalius/symphonic-mpd
I am sorry but license issues are taken quite seriously in open source.
Thank you for your effort.
I just want to bring Tidal to SMPD on Pi 4 !
Look like big work.
Hi thanhvo31,
Tidal! It's so worth it!
It didn't work out. Sorry about that.
I think the best thing to do is to express your requests to the openhome team.
I'm sure they'll want to know what the users want.
For a while, I'm going to focus on developing the topic I'm working on.
I'm aiming for the end of the year, so if there's any progress then I'll write back.
The purpose of the theme is to distribute the load between two machines, one for decoding and one for I2S output.
I will be using a dedicated driver for PCM data transmission and reception.
I will write incoming packets from the NIC FIFO to a buffer in kernel space, then bypass the kernel TCP/IP stack and slot swap only the PCM data packets into a separate ring buffer.
Then I'll DMA from this ring buffer to the serializer.
I'll only have to ldr/str once. There's no way to reduce it any further.
Doesn't that sound interesting?
Many of us have experienced a change in sound quality by lowering the load.
I'm curious to see what it sounds like beyond pushing the low load.
The timing of the data transmission is controlled by the receiver.
A chunk of PCM on a UDP packet will flow quietly and steadily through the LAN at a constant rate.
Tidal! It's so worth it!
It didn't work out. Sorry about that.
I think the best thing to do is to express your requests to the openhome team.
I'm sure they'll want to know what the users want.
For a while, I'm going to focus on developing the topic I'm working on.
I'm aiming for the end of the year, so if there's any progress then I'll write back.
The purpose of the theme is to distribute the load between two machines, one for decoding and one for I2S output.
I will be using a dedicated driver for PCM data transmission and reception.
I will write incoming packets from the NIC FIFO to a buffer in kernel space, then bypass the kernel TCP/IP stack and slot swap only the PCM data packets into a separate ring buffer.
Then I'll DMA from this ring buffer to the serializer.
I'll only have to ldr/str once. There's no way to reduce it any further.
Doesn't that sound interesting?
Many of us have experienced a change in sound quality by lowering the load.
I'm curious to see what it sounds like beyond pushing the low load.
The timing of the data transmission is controlled by the receiver.
A chunk of PCM on a UDP packet will flow quietly and steadily through the LAN at a constant rate.
My friend happens to be a member of the R&D club and has communicated with several other members individually. All of them regard this club administrator as the most harmful. He has been blacklisted among the Japanese hifi stores.
As can be seen, it is his habit to tell a lie and to claim to whatever he feels uncomfortable. A github account created more than three years ago cannot be a preparation for source disclosure the author started to think about less than a month ago. I assume it was the administrator's suggestion to delete the github account.
The author seems to be extremely afraid of being identified in his real life, and may stop distributing his software at any time.
Dear the R&D club administrator,
if you truly admire the talent of the author and love his software, resign the club administrator, delete all your posts, close your ugly homepage, and never appear in public again.
As can be seen, it is his habit to tell a lie and to claim to whatever he feels uncomfortable. A github account created more than three years ago cannot be a preparation for source disclosure the author started to think about less than a month ago. I assume it was the administrator's suggestion to delete the github account.
The author seems to be extremely afraid of being identified in his real life, and may stop distributing his software at any time.
Dear the R&D club administrator,
if you truly admire the talent of the author and love his software, resign the club administrator, delete all your posts, close your ugly homepage, and never appear in public again.
Hi babalius,
You might want to ask that friend to look at your comment and advise you if there are any funny descriptions.
They should immediately notice the ridiculousness of the part you guessed at and point it out to you.
When you're done revising, please write again.
Next time, everyone should be able to understand your point.
There is no need for you to be embarrassed.
It's because your friend didn't do a good job of explaining things.
You might want to ask that friend to look at your comment and advise you if there are any funny descriptions.
They should immediately notice the ridiculousness of the part you guessed at and point it out to you.
When you're done revising, please write again.
Next time, everyone should be able to understand your point.
There is no need for you to be embarrassed.
It's because your friend didn't do a good job of explaining things.
